Live data from Hacker News

Firefox 55 and Selenium IDE

seleniumhq.wordpress.com

111–120 of 132 posts

Re: Firefox 55 and Selenium IDE

#111

Earlier quoted context omitted.

We at http://www.trinityradar.com/ provide browser automation service. We stopped working with Firefox a few months ago since less and less people are using firefox now. We run chrome browser on cloud. Full disclosure: I work for Trinity Radar.

Chrome is the new IE

In case anyone wonders, here are some points to get you started:

[X] created by a company that can't be trusted

[X] made mandatory by lazy devs && corporate bean counters who refuse to let other developers do the professional thing and make stuff work cross platform

[X] worse than the alternatives in many ways except being feature-by-feature and bug-by-bug compatible with the market leaders (yep: memory use, battery use, extensions)

Re: Firefox 55 and Selenium IDE

#112
post #10

Selenium IDE is a tremendous help for projects that want integration testing, and want to enable any team member to write ballpark tests. Selenium IDE saved us hundreds or thousands of hours. For example, my team took an existing web app with no tests, and had the project manager and junior business analysis go through the entire app with the Selenium IDE, writing tests. This enabled our dev team to start coding fast…

Have you tried Helium? https://heliumhq.com/

Re: Firefox 55 and Selenium IDE

#113

Earlier quoted context omitted.

Yes, usage of isolated browser instances should be restricted to information within a single context or risk profile. E.g. a stateless, frequently rebooted VM for occasional use of a particular extension. Or a Bromium micro-VM for each tab, redirect, etc.

This is totally impractical, or people would be already doing this when using other browsers as a defense in depth thing.

Bromium claims to be seamless to end-users, but it's not available to consumers, except on some HP devices, https://www.theregister.co.uk/2017/02/13/hp_bromium_virtuali...

As for practicality, if your daily workflow involves a browser extension that has no replacement, the options are:

  - stop doing the task
  - all browsing with insecure browser, no isolation
  - single task with insecure browser, no isolation
  - single task with insecure browser, some isolation
Most people will do #2 or #3. Those who care about security will do #4, with quality of isolation dependent on their threat model.

Re: Firefox 55 and Selenium IDE

#114
post #107

Earlier quoted context omitted.

https://arewewebextensionsyet.com/ Unfortunately 75%+ of the most used extensions either arnt ported, wont be ported, or cant be ported. The situation is pretty grim, mozilla really needs to delay this move, web extensions arnt capable of supporting the functionality lots of these addons require, and its not like XUL is even going away in the near/midterm, this is purely an administrative decision. If they plow forwa…

Although I don't expect it, I can imagine Mozilla delaying it a bit if they have reasonable belief most of those will be ported in a reasonable amount of time. That said, saying it's an administrative decision really misses the point. XUL support hampers performance, slows down Firefox development, and includes security issues. Those are serious reasons for moving away from them. They might not weigh up to the benefi…

They won't delay it since they've already begun breaking the old XUL extensions API in order to make room for new improvements. This is getting quite tiresome at this point -- extension devs have had over a year to port. If the extension devs are targeting Chrome too, it's easier to use WebExt than XUL anyway, and if they haven't spent this time to engage with Mozilla about expanding the WebExt spec so their extension is not possible in WebExt, the fault lies with the extension dev.

Re: Firefox 55 and Selenium IDE

#115

I wonder if there's anyone here from SauceLabs or or any other company that does browser automation as a service -- was this easy to see coming? Is everything pants-on-fire there at the moment?

We knew this was coming down the track, but the selenium project lacked the people to prevent it from happening. Sauce Labs donated Selenium Builder (nee Sauce Builder) to the project to try and help. Applitools have recently leant some engineering muscle to the problem. The problem breaks down into two main areas: * Technical: the underpinnings have switched from the XPI model to Web Components. Mozilla are doing wh…

Thanks for the response!

Always curious how moves like this help people who are actually doing stuff in the browser automation/testing scene (I am just a trend follower/leech off the work being done), glad to hear you guys were ready and props on thinking ahead.

Re: Firefox 55 and Selenium IDE

#116
post #81

There seems to be a certain amount of confusion on this thread, so just to be sure that it's clear, Selenium itself will continue to work with future releases of Firefox. This means that existing WebDriver-based browser automation remains compatible with with Firefox 55+. SauceLabs', and other testing-infrastructure-as-a-service providers' support for Firefox will be unchanged. The only thing that will stop working i…

> there are alternatives in development that are targetting a similar niche

Which tools are out there (open source and as easy to use as Selenium IDE)?

Re: Firefox 55 and Selenium IDE

#117
post #10

Selenium IDE is a tremendous help for projects that want integration testing, and want to enable any team member to write ballpark tests. Selenium IDE saved us hundreds or thousands of hours. For example, my team took an existing web app with no tests, and had the project manager and junior business analysis go through the entire app with the Selenium IDE, writing tests. This enabled our dev team to start coding fast…

Have you tried Helium? https://heliumhq.com/

[deleted]

Re: Firefox 55 and Selenium IDE

#118
post #81

There seems to be a certain amount of confusion on this thread, so just to be sure that it's clear, Selenium itself will continue to work with future releases of Firefox. This means that existing WebDriver-based browser automation remains compatible with with Firefox 55+. SauceLabs', and other testing-infrastructure-as-a-service providers' support for Firefox will be unchanged. The only thing that will stop working i…

> there are alternatives in development that are targetting a similar niche Which tools are out there (open source and as easy to use as Selenium IDE)?

Here are some IDE alternatives for record and replay:

- iMacros (Firefox + Chrome, not open-source)

- Kantu IDE Light (Chrome, open-source)

- E2E Test Builder (Chrome, open-source)

None is 1:1 replacement (yet?), each has a different focus.

there is also this thread: https://news.ycombinator.com/item?id=13586904

Re: Firefox 55 and Selenium IDE

#119
post #4

I'd be curious to see what the usage stats on the IDE are; my company (Mozilla, ironically) uses Selenium a ton, but as far as I know we write all of our tests by hand instead of with the IDE since it allows you to use patterns like Page objects to make your tests more maintainable in the long run. Although the last time I used the IDE was years ago, so it may be more flexible than it used to be. Does anyone extensiv…

We started to adapt Selenium IDE to allow people who don't have extensive coding backgrounds to automate manual testing they're already doing. It provided massive time savings when used properly. This news will likely completely kill the initiative.

Re: Firefox 55 and Selenium IDE

#120
post #107

Earlier quoted context omitted.

Although I don't expect it, I can imagine Mozilla delaying it a bit if they have reasonable belief most of those will be ported in a reasonable amount of time. That said, saying it's an administrative decision really misses the point. XUL support hampers performance, slows down Firefox development, and includes security issues. Those are serious reasons for moving away from them. They might not weigh up to the benefi…

They won't delay it since they've already begun breaking the old XUL extensions API in order to make room for new improvements. This is getting quite tiresome at this point -- extension devs have had over a year to port. If the extension devs are targeting Chrome too, it's easier to use WebExt than XUL anyway, and if they haven't spent this time to engage with Mozilla about expanding the WebExt spec so their extensio…

I think thats pretty unfair when mozilla has been straight up refusing to implement webextension equivilents to XUL based functionality that a lot of addons depend on.

Such as the fact there is no way to enumerate what sites have html5 local storage stuff stored, thus no way to control or clear it on a per site basis, and they are not interested in changing this, rendering an addon like what self destructing cookies does imposisble...

https://bugzilla.mozilla.org/show_bug.cgi?id=1329745

Or the ability for extensions to construct permission sandboxing

https://bugzilla.mozilla.org/show_bug.cgi?id=1353468

There is objectively a LOT of functionality that is just plain never going to be implemented, thats far from the fault of the extension authors.

Many have been trying to work with mozilla to push in the functionality they need, but if they just get disregaurded and ignored what are they supposed to do exactly?

Don't try to place the blame for this on the extension authors.

Post reply on HN