Firefox 55 and Selenium IDE(seleniumhq.wordpress.com)
seleniumhq.wordpress.com
Firefox 55 and Selenium IDE
https://seleniumhq.wordpress.com/2017/08/09/firefox-55-and-selenium-ide/
131 comments
> 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)?
Which tools are out there (open source and as easy to use as Selenium IDE)?
I am evaluating E2E Test Builder and Kantu Selenium IDE Light, both are Chrome extensions and open-source.
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
- 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
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, and refactoring fast.
In parallel our QA team then took those tests and used them as first-drafts to create even better tests that were generic, maintainable, randomizable, and so forth.
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, and refactoring fast.
In parallel our QA team then took those tests and used them as first-drafts to create even better tests that were generic, maintainable, randomizable, and so forth.
If you say that "Selenium IDE saved us hundreds or thousands of hours", why not convince your company to donate 10% of the money saved back to Selenium, so that they maybe have the resources to actually pay someone to continue development of these useful tools?
[deleted]
This is not how capitalism works
Actually it is; there are subsidies for open source projects all over the VC funded technology industry.
oddly enough, when your capitalist corporation would implode if the open source operating system it depends upon were to suddenly stop development... the corporation needs to pay to support the project or risk falling behind to its capitalist contemporaries!
the system works (in this example)!
the system works (in this example)!
Except when it is.
Investing resources is great marketing, trains your developers if they're working on it and gains you influence to improve the parts you need improved.
Investing resources is great marketing, trains your developers if they're working on it and gains you influence to improve the parts you need improved.
I think that there are plenty of reasons for companies not to contribute. Not many companies have spare engineering capacity for working on OSS. Of those that do, they have to choose where to spend the effort --- testing tools aren't as exciting as Machine Learning, or the latest JS framework, or.... Of course, once you start hacking on the code, you may find you like it a lot. :)
The IDE is a mature, and old product too, so even if engineers can spend time hacking on it, getting up to speed can be tricky. The Selenium project has an active "selenium-developers" google group, a #selenium IRC channel on freenode, and a Slack channel, where many of the core team can be found.
Which is a long way of saying that it's not always easy for even motivated individuals and companies to contribute to OSS.
The IDE is a mature, and old product too, so even if engineers can spend time hacking on it, getting up to speed can be tricky. The Selenium project has an active "selenium-developers" google group, a #selenium IRC channel on freenode, and a Slack channel, where many of the core team can be found.
Which is a long way of saying that it's not always easy for even motivated individuals and companies to contribute to OSS.
Just to get an other datapoint: we used to build tests for selenium with selenium ide too, but quickly found out that the used selectors for the elements often had to be manually tweaked, and so we switched to http://nightwatchjs.org/ for our tests, and write them by hand.
Tests are more reliable now, and devs are happy with it. Based on my (limited) experience, selenium ide is not something that is absolutely needed. It's a fine piece of software, but devs can do fine without.
Tests are more reliable now, and devs are happy with it. Based on my (limited) experience, selenium ide is not something that is absolutely needed. It's a fine piece of software, but devs can do fine without.
Are these E2E tests robust?
I found they often break easily
I found they often break easily
Yes they work. The only thing you have to watch out for is the timing for the assertions with
That's the only gotcha we found we have to be careful about.
.waitForElementVisible('[name="main"]', 10000)
That's the only gotcha we found we have to be careful about.
[deleted]
Of course, Selenium (WebDriver) still works. However, this might be the push for people to investigate other test frameworks. I found TestCafe by DevExpress (https://devexpress.github.io/testcafe/) is a great tool and is also completely open source (MIT!). It's a shame that the community is so small because it's so powerful. Maybe this might be the push that moves some more people over?
Their sites aren't very clear - what differentiates their open source version (http://devexpress.github.io/testcafe/) from the paid ($500/dev/year) version? (https://testcafe.devexpress.com/)
You can read about the difference between free and paid versions here: https://testcafe-discuss.devexpress.com/t/what-is-the-differ...
There is a reply here apparently from a developer of testcafe, but it's 'dead'. It's a perfectly reasonable comment, so hopefully the mods can resurrect it - and check if the account is banned for no reason (that's the only comment it made, so I don't see why).
The developers are in Russia maybe it's an IP ban?
I found out about Testcafe a few weeks ago. It's such a great product but too less people even know about it.
> Maybe this might be the push that moves some more people over?
You posted this on HN. Be careful for what you wish for ;)
You posted this on HN. Be careful for what you wish for ;)
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 extensively use the IDE?
Does anyone extensively use the IDE?
This is the great feature of the Ide. Kick start your tests, then you "upgrade" to hand coding. Great for learning about a new system, or to get help from less technical people when the house is on fire.
Back when I was using it (about 4 years ago), we used it mostly as a debugging aid to understand what actually should go into some expressions.
Also some people from QA, without coding skills, would use it.
Also some people from QA, without coding skills, would use it.
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.
IDE is a good way to kickstart the tests, it allows non-technical people to create skeletons for tests which can then be touched up/prettified/refactored by devs.
This describes exactly my/our experience. Test recording can be a great time saver when used properly. Sure, a Java or Python guru can write a webdriver test in "seconds", but she usually does not want too. Plus the "seconds" often turn into hours of coding and debugging ;-)
I didn't know this existed. I always write the tests in JS using .click() .focus() etc.
previous company used it quite extensively, especially if there's a new feature the enterprise software that needs testing by the QA team
we did write the test by hand tho, very DSL-like & really targeted at non-programmer
we did write the test by hand tho, very DSL-like & really targeted at non-programmer
I have a feeling that the kind of firms that were benefiting from Selenium IDE (hiring cheap labor to write tests as an afterthought) were not the kind of firms that would spend money to contribute.
This isn't sustainable.
This isn't sustainable.
Or the kind of engineers capable of contributing to the software.
Test recorders are an antipattern. They lure you with their "no programming required!" siren call, but the generated scripts invaribly end up as a fragile, poorly abstracted mess.
GUI tests suites, especially those created with recorders, are prone to become unmaintainable beasts full of flaky tests.
This old interview with Bret Pettichord makes good points about the use of recorders: https://youtu.be/s_CUPs6xAWw?t=590
GUI tests suites, especially those created with recorders, are prone to become unmaintainable beasts full of flaky tests.
This old interview with Bret Pettichord makes good points about the use of recorders: https://youtu.be/s_CUPs6xAWw?t=590
Disagree 51%. Recording tests works well and saves tons of time in specific scenarios. It works especially well for "throw away" test cases that you need only for a few days, for example during development of a specific feature. So I consider your statement way too black and white.
UI-level tests are the only kind that reliably test the full stack of your application. No amount of unis testing will catch a missing button or a wrong config setting.
And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse.
The best way to make web UI tests stable is to involve engineers and make sure that the pages are structured in the way that make automation and validation easy. Usually the changes required for this are trivial. When they're not, it often points out something in the UI that doesn't make sense anyway, like having no confirmations for user actions.
And in any case, automated UI tests are still better than manual UI test, which is what a lot of people are stuck with.
And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse.
The best way to make web UI tests stable is to involve engineers and make sure that the pages are structured in the way that make automation and validation easy. Usually the changes required for this are trivial. When they're not, it often points out something in the UI that doesn't make sense anyway, like having no confirmations for user actions.
And in any case, automated UI tests are still better than manual UI test, which is what a lot of people are stuck with.
I agree that is is important to structure the application to facilitate testing. But I find this surprising:
> And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse.
In my experience, writing the tests manually for sufficiently "regular" applications ends up being more maitainable because you can put repeated logic in shared functions and classes, making it easier to adapt to changes in the GUI. Page Objects are an example of that: https://github.com/SeleniumHQ/selenium/wiki/PageObjects
Also, writing the tests manually lets you use "explicit waits". http://elementalselenium.com/tips/47-waiting Specifying exactly what we expect to happen tends to be more robust (and faster) than either using static sleeps or some kind of implicit wait. Recorders tend to have problems finding concrete things to wait for, especially for very dynamic pages.
(That said, I'm not against using something like Chrome DevTools to identify elements in the page, evaluate potential selectors, and so on. That is indeed useful.)
> And while recorders present some challenges, manually coding UI-level tests make the maintainability issue an order of magnitude worse.
In my experience, writing the tests manually for sufficiently "regular" applications ends up being more maitainable because you can put repeated logic in shared functions and classes, making it easier to adapt to changes in the GUI. Page Objects are an example of that: https://github.com/SeleniumHQ/selenium/wiki/PageObjects
Also, writing the tests manually lets you use "explicit waits". http://elementalselenium.com/tips/47-waiting Specifying exactly what we expect to happen tends to be more robust (and faster) than either using static sleeps or some kind of implicit wait. Recorders tend to have problems finding concrete things to wait for, especially for very dynamic pages.
(That said, I'm not against using something like Chrome DevTools to identify elements in the page, evaluate potential selectors, and so on. That is indeed useful.)
I co-founded a company called Functionize (https://www.functionize.com/) and we found the same, but the problem is one of assumptions: should you be generating scripts in the first place?
What we ended up doing on our platform was discard the notion of generated scripts entirely. Everything becomes data, not source code. If you're willing to make the tradeoff to a cloud service vs. having the code (many businesses are), it's a great model. If you prefer having control over the code, it will drive you crazy.
What we ended up doing on our platform was discard the notion of generated scripts entirely. Everything becomes data, not source code. If you're willing to make the tradeoff to a cloud service vs. having the code (many businesses are), it's a great model. If you prefer having control over the code, it will drive you crazy.
That's why I always used the selenium UI script as a starting point when I was doing web app QA. It was easier in my experience to take the generated output and eliminate unnecessary steps and clean up the selectors than to start from scratch.
Sounds like app specific recorders could be more robust and resilient to changes.
All you said is true, but this doesn't stop Selenium IDE of being a valuable tool. You just need to know when to use it. Without it a lot systems in my company would have zero tests. Not even bad and fragile ones.
One could argue that bad or fragile tests can be more harmful than having no tests at all.
Exactly, there is a degreee of flakiness beyond which you don't gain much assurance from your tests and you spend more time fighting fires in the testsuite than actually testing your app.
>You just need to know when to use it
When exactly is that ? Never ? That clusterfuck of generated code is useless.
When exactly is that ? Never ? That clusterfuck of generated code is useless.
> Test recorders are an antipattern.
Selenium IDE is a useful tool for QA and a lot of user use case. Can people stop calling anything they don't like "antipattern"? All tools are useful when used correctly. Anything can be "an anti pattern" when used incorrectly.
Selenium IDE is a useful tool for QA and a lot of user use case. Can people stop calling anything they don't like "antipattern"? All tools are useful when used correctly. Anything can be "an anti pattern" when used incorrectly.
For this exact reason I made an extension for chrome that covers some of it's features:
https://chrome.google.com/webstore/detail/e2e-test-builder/p...
I'd rather tag elements of interest and record (and adjust manually) than write everything in code.
https://chrome.google.com/webstore/detail/e2e-test-builder/p...
I'd rather tag elements of interest and record (and adjust manually) than write everything in code.
Looks interesting.
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 what they think is best for their browser, and I know that they make their choices with thought and data.
* People: every successful OSS project has a company or person acting as its champion. The selenium project has people working flat out for the language bindings, the w3c "WebDriver" spec, grid, and supporting the community. We lack a champion with the time to spend on IDE.
We can fix the technical side of things. The thing that we could really do help with is the people-side....
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 what they think is best for their browser, and I know that they make their choices with thought and data.
* People: every successful OSS project has a company or person acting as its champion. The selenium project has people working flat out for the language bindings, the w3c "WebDriver" spec, grid, and supporting the community. We lack a champion with the time to spend on IDE.
We can fix the technical side of things. The thing that we could really do help with is the people-side....
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.
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.
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.
Your site says "Run tests in Chrome, Firefox, or in IE 11" - so is that claim still true or am I missing something?
We need to update homepage along with all screenshots since all screenshots with Firefox are outdated now.
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)
[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)
But that has nothing to do with the IDE no longer being available, but merely as a cost-saver for you guys (I presume).
Note that SauceLabs, Browserstack etc. will continue to work. This was just an extension that allowed you to create tests by click through your website rather than writing them by hand. Resulted in far brittler tests, but useful to some apparently.
Wow, that's really sad to hear!
I wonder if, instead of abandoning the project, they could put together a patron sponsorship to fund further development?
I'm sure there are plenty of companies out there that rely on firefox and selenium and would be more than happy to help contribute?
I wonder if, instead of abandoning the project, they could put together a patron sponsorship to fund further development?
I'm sure there are plenty of companies out there that rely on firefox and selenium and would be more than happy to help contribute?
> since the start of the year, there are only 11 people who have made more than 10 commits, with two people accounting for more than half of those. Since 2016, only one person has been maintaining the IDE.
Apparently they are not.
Apparently they are not.
> rely on firefox and selenium
... but not the IDE, which is what is being abandoned. Most people don't use the IDE, or use it for a bit before they learn how to do things manually (coders like to code).
... but not the IDE, which is what is being abandoned. Most people don't use the IDE, or use it for a bit before they learn how to do things manually (coders like to code).
I'm getting the impression that a lot of extension developers are not just complaining about these changes but also making the decision to shut down their development. Feels like it could be pretty bad news for Firefox.
I believe that this was communicated by the Firefox team more than a year ago, so it shouldn't be news to anyone who have been maintaining their extension(s). For all those people who developed something and then moved on to something else, it may seem like that year passed really quickly - and the only option left is to drop the extension.
I didn't mean to imply people are surprised. They have made the decision regardless of the amount of notice.
Maybe instead of "will not be fixed" the headline should say "contributors needed?"
Can't upvote this enough!
YES!
In the last hours since submitting this link to HN, I started using the Selenium IDE made by Kantu:
https://chrome.google.com/webstore/detail/kantu-browser-auto...
It works well for what it does and covers basic recording/replay for the core commands. But it is a new project, and by no means a full replacement yet. Code on Github (GPL license).
https://chrome.google.com/webstore/detail/kantu-browser-auto...
It works well for what it does and covers basic recording/replay for the core commands. But it is a new project, and by no means a full replacement yet. Code on Github (GPL license).
This extension uses the Webapi... so I assume it can be "backported" to Firefox?
[deleted]
I am very sad to hear this. Yes, this is antipattern, yes, selectors are doomed, but I had so many good experiences of introducing automated integration tests with IDE to QA teams, who later moved to hand-written tests. Learning curve was small and benefits were quick.
What are some good open source tools in the area of rapid development ofweb end-to-end tests?
I know about Robot Framework, which does not record and replay but instead uses an AppleScript type english-flavoured DSL. But still seems quicker than scripting Selenium.
I know about Robot Framework, which does not record and replay but instead uses an AppleScript type english-flavoured DSL. But still seems quicker than scripting Selenium.
I like SpecFlow (http://specflow.org/), a .net flavor of cucumber. It's not quite rapid development, but as with others here I've found the test recorders to be too brittle to justify the upfront time savings anyway.
I've used it for front end testing and database/view testing.
I've used it for front end testing and database/view testing.
Might it still work in SeaMonkey? Unless SeaMonkey also plans to change the extension mechanism...
Why would they maintain it? Browsers are providing headless ways to accomplish the same.
The selenium IDE is a tool that records actions done in the browser for replay, not the test driving component.
Is there like a electron for firefox xul? There is actually
is https://developer.mozilla.org/en-US/docs/Archive/Mozilla/XUL...
edit: answering my own question.
edit: answering my own question.
There used to be, but it got killed https://en.wikipedia.org/wiki/XULRunner
We (ab)use Selenium on headless Linux servers for task automation where no API is available. I hope this isn't affected - otherwise I'll have to `sudo apt-mark hold firefox`.
Suggestions for alternative software for this purpose?
Suggestions for alternative software for this purpose?
Selenium will continue working, and is actively supported by Mozilla. The IDE (the plugin that allowed UI-based recording of tests) is the only thing that's not working.
sure - but this might very well indicate a trend.
who on earth is downvoting my comments and why?
when the developers involved with Selenium suddenly decide to just drop a browser for one of their sub-projects then this might very well indicate a trend - even if it's just that firefox is less actively supported in future.
when the developers involved with Selenium suddenly decide to just drop a browser for one of their sub-projects then this might very well indicate a trend - even if it's just that firefox is less actively supported in future.
I understand where your concern is coming from, but I think you're missing a few of the pieces:
* When it comes to Selenium, Simon (the guy you replied to) is about as authoritative a voice as they come.
* The death of Selenium IDE is anything but sudden. It's really been more of a zombie for years and just kept kicking along. It's been saved from absolute death a few times over by generous support of volunteers willing to pick it up. But I don't think anyone tracking Selenium development is going to be surprised by this move.
* Selenium has been on a multi-year quest to shift support for the browser drivers out to the browser vendors by way of the WebDriver W3C standard [1]. The goal is for Selenium to be more of an interface to browser-specific implementations of the WebDriver specification more than anything else. Which is to say, Selenium dropping support for a particular browser shouldn't be too concerning because the major browser vendors will be maintaining their own driver implementation.
* Slightly related to the above point, but Selenium IDE is not and never has been maintained by Mozilla. The Firefox WebDriver implementation, however, is. And Mozilla is heavily involved in the editing and drafting of the WebDriver specification.
Hopefully that helps assuage your concerns.
[1] -- https://www.w3.org/TR/webdriver/
* When it comes to Selenium, Simon (the guy you replied to) is about as authoritative a voice as they come.
* The death of Selenium IDE is anything but sudden. It's really been more of a zombie for years and just kept kicking along. It's been saved from absolute death a few times over by generous support of volunteers willing to pick it up. But I don't think anyone tracking Selenium development is going to be surprised by this move.
* Selenium has been on a multi-year quest to shift support for the browser drivers out to the browser vendors by way of the WebDriver W3C standard [1]. The goal is for Selenium to be more of an interface to browser-specific implementations of the WebDriver specification more than anything else. Which is to say, Selenium dropping support for a particular browser shouldn't be too concerning because the major browser vendors will be maintaining their own driver implementation.
* Slightly related to the above point, but Selenium IDE is not and never has been maintained by Mozilla. The Firefox WebDriver implementation, however, is. And Mozilla is heavily involved in the editing and drafting of the WebDriver specification.
Hopefully that helps assuage your concerns.
[1] -- https://www.w3.org/TR/webdriver/
Chrome has a relatively new headless mode and there are Puppeteer and probably some more language bindings for it.
https://developers.google.com/web/updates/2017/04/headless-c...
https://developers.google.com/web/updates/2017/04/headless-c...
This is what is going to happen to most extensions. Mozilla is bonkers, doing this. They're going to regret it.
Only about 20% of Firefox add-ons have been converted to WebExtension format.
One of the headaches is that access to local storage is asynchronous (in the "promise" sense) in WebExtensions. As a result, if you want something based on stored data such as a stored script or a blocklist to happen early, during page load, you can't get it to run soon enough. This breaks Greasemonkey[1] and NoScript.[2] WebExtensions needs some extensions for them to work. The new features appear to be coming, but represent divergence from cross-platform WebExtensions, and they may not be working in the release version before the XUL death date.
Fortunately, my own add-on didn't need anything that isn't working yet, so I had a successful port.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1332273 [2] https://blog.mozilla.org/addons/2017/08/01/noscripts-migrati...
One of the headaches is that access to local storage is asynchronous (in the "promise" sense) in WebExtensions. As a result, if you want something based on stored data such as a stored script or a blocklist to happen early, during page load, you can't get it to run soon enough. This breaks Greasemonkey[1] and NoScript.[2] WebExtensions needs some extensions for them to work. The new features appear to be coming, but represent divergence from cross-platform WebExtensions, and they may not be working in the release version before the XUL death date.
Fortunately, my own add-on didn't need anything that isn't working yet, so I had a successful port.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1332273 [2] https://blog.mozilla.org/addons/2017/08/01/noscripts-migrati...
The 20% figure doesn't say that much - you'd need to know how many of the extensions used most often are ported. I can very much imagine there being a long tail of extensions that nobody uses.
Also take into account how many Chrome extensions are ported over now that it's easy. For example, the only extension I use that won't get ported over is VimFx, but Vimium has now become available which does exactly the things I used VimFx for.
Also take into account how many Chrome extensions are ported over now that it's easy. For example, the only extension I use that won't get ported over is VimFx, but Vimium has now become available which does exactly the things I used VimFx for.
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 forward anyways its going to really, really hurt firefox.
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 forward anyways its going to really, really hurt firefox.
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 benefits to you, but you can't deny that they're there.
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 benefits to you, but you can't deny that they're there.
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.
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.
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.
There is that. For big-name extensions like UBlock Origin and Greasemonkey, there's a Mozilla bug which is used as a tracker for Firefox-side issues which need to be fixed. Lesser extensions don't get that kind of attention.
When I was porting my extension, my big worry was "is there going to be something I need to do that doesn't work?" But there were no show-stopper bugs.
When I was porting my extension, my big worry was "is there going to be something I need to do that doesn't work?" But there were no show-stopper bugs.
> if you want something based on stored data such as a stored script or a blocklist to happen early, during page load, you can't get it to run soon enough. This breaks Greasemonkey[1] and NoScript.[2]
How does UBO work? Or is it broken too?
EDIT: Thanks for the replies. I know there's a webext version of UBO, but that doesn't really explain why the problem I quoted would affect noscript and greasemonkey but not ubo?
How does UBO work? Or is it broken too?
EDIT: Thanks for the replies. I know there's a webext version of UBO, but that doesn't really explain why the problem I quoted would affect noscript and greasemonkey but not ubo?
UBlock Origin has a working version in the dev channel [1]
[1] https://addons.mozilla.org/en-US/firefox/addon/ublock-origin...
[1] https://addons.mozilla.org/en-US/firefox/addon/ublock-origin...
There were problems, but they seem to be past them.[1]
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1309926
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1309926
At least the ones I use are all migrating and the issue at the moment is more, that new versions are pushed to the Mozilla store but waiting for approval - If Mozilla doesn't speed up that process, a lot of extensions will probably be missing for a while.
The only really sad thing is that pentadactyl/vimperator won't work at all and require complete rewrites to cover at least part of the old functionality.
The only really sad thing is that pentadactyl/vimperator won't work at all and require complete rewrites to cover at least part of the old functionality.
Are they? The old system is holding improvements back. If they move to a superset of Chrome's they can still get Chrome add-ons and then some.
If people value the old extension system that much, then it will live on in one of the FF forks. Regardless Firefox will finally get faster, more responsive, more secure, AND still have a better extension API than Blink/WebKit.
If people value the old extension system that much, then it will live on in one of the FF forks. Regardless Firefox will finally get faster, more responsive, more secure, AND still have a better extension API than Blink/WebKit.
The only reason to use Firefox is because many of its extensions are not possible in any other browser. Watch the market share drop after the extensions are dumbed down to Chrome level.
Only reason?
I use Firefox because it's way faster, more stable, and from an organization that I trust. I run Nightly, which means that I made the shift to Webextensions last week. My only extension that didn't have a WE version or alternative was LastPass. No surprise, since they seem to take such poor care of their extensions anyway. That's a Deal Breaker for me, so I switched to pass.
I use Firefox because it's way faster, more stable, and from an organization that I trust. I run Nightly, which means that I made the shift to Webextensions last week. My only extension that didn't have a WE version or alternative was LastPass. No surprise, since they seem to take such poor care of their extensions anyway. That's a Deal Breaker for me, so I switched to pass.
I'm not sure if it's faster yet, but Firefox 57+ is getting very good due to all the radical changes they have been making in the last year. If you haven't checked out Firefox in a while I think you should try Firefox Nightly...
Fwiw I haven't had an issue with Lastpass, before or after the change to the extension API. They appear to be using the exact same code base as in the Chrome extension and that's fine by me.
Same here... Firefox remains my default browser for its indepence. And it is great to see it improve. Once they catch up with the Webapi I hope they keep expanding it beyond a Chrome copy.
Firefox is way faster than what? IE6?
Firefox nightly, which will end up as FF57, uses less memory than Chrome and is faster. (Windows, x64). One of the reasons this was possible was disabling the old extension system. Does it hurt? Sure. Was it needed? Yes.
Do you have any evidence this is actually true? XUL is still there, the firefox UI is still written in it and it will be for quite some time to come. I find it hard to beleive disallowing XUL extensions have significantly sped anything up.
Disallowing XUL extensions made it possible to make many underlying changes that otherwise would break a lot of them. There are plenty of long-lasting tickets on Bugzilla being finally tackled in Firefox 57.
I don't use extension any extension but i use Firefox on Desktop and Mobile. From end user wait time etc i dont see any difference between firefox and chrome. For some reason firefox is seem to be faster than chrome on mobile. I use firefox focus mostly on mobile. It would be really sad to see firefox go away as that is only one which is not tied to OS or tied to provider of webmail etc. I see firefox as a product from browser company.
I dunno - I'm a very technical user and I use a pretty vanilla Firefox mostly just because I like/trust Mozilla and don't want to support the web becoming a Webkit / Chrome monoculture.
The only addon I use is LastPass. They support the new extension format just fine. I'm looking forward to the architectural changes coming in Servo, etc, which WebExtensions help make possible. I can't be the only user like me.
The only addon I use is LastPass. They support the new extension format just fine. I'm looking forward to the architectural changes coming in Servo, etc, which WebExtensions help make possible. I can't be the only user like me.
Ditto here. I use Firefox exclusively and all of my extensions are supported - OneTab, ublock origin, Lastpass. I fail to understand the narrative of "the only thing keeping FF alive is the handful of extensions that can't be ported to Chrome". I don't think the extension API is where this battle will be fought anyway. Performance and reliability are what users care about - is the browser fast to open, are pages fast to load, is it making other apps slow (memory and CPU consumption), how many tabs can I keep open, does it hang, does it crash, does any website fail to load/misbehave?
I'm confident Firefox will outstrip Chrome in these areas in the next year or so. But if it doesn't... it will die a slow death and the people on HN will assure us it was because NoScript didn't work anymore.
I'm confident Firefox will outstrip Chrome in these areas in the next year or so. But if it doesn't... it will die a slow death and the people on HN will assure us it was because NoScript didn't work anymore.
Thankfully, NoScript will still work just fine - it's already a WebExtension/XUL hybrid and Firefox 57 will bring last changes needed to make it fully WebExtensionified :)
>If people value the old extension system that much, then it will live on in one of the FF forks.
Using a fork is also bonkers. I don't trust the security of my web browsing on a fork. Most people won't, either. So Firefox will just get this nice metric saying "most people have not moved to a fork" and will be able to pat themselves in the back. But it's bogus.
Using a fork is also bonkers. I don't trust the security of my web browsing on a fork. Most people won't, either. So Firefox will just get this nice metric saying "most people have not moved to a fork" and will be able to pat themselves in the back. But it's bogus.
Forks (or old versions of Firefox + extensions) can be run in isolated VMs on platforms like Qubes.
That's kind of a moot point when your browser handles most of your online interactions (and therefore a good chunk of your online identity, which is quite valuable to most people). Even if you isolate it as much as you can, which is a good thing to do in any case, it can still do a lot of damage without escaping the sandbox.
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:
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
> Mozilla is bonkers, doing this.
No they are not. Anyone who has done (or tried to do) any cross-browser extension development will attest that working with Chrome-style apis is so much faster than trying to make sense of XUL. Look at how many new extensions start life as Chrome-only these days. Chrome did to Firefox what Firefox did to IE - which had an extension mechanism that required C++ (!). Ease of development always wins, because humans are lazy. Mozilla tried for years (and failed) to match that ease of development, and then decided XUL is not a hill worth dying on - especially considering how it also held back a lot of performance-related improvements.
As others have said, it will hurt but it's worth doing if the browser is to survive. It would have probably come sooner had it not been for the FFOS distraction. Once the ecosystem is fully rebased on webextensions, then Mozilla can try an embrace-and-extinguish play if they really want to.
No they are not. Anyone who has done (or tried to do) any cross-browser extension development will attest that working with Chrome-style apis is so much faster than trying to make sense of XUL. Look at how many new extensions start life as Chrome-only these days. Chrome did to Firefox what Firefox did to IE - which had an extension mechanism that required C++ (!). Ease of development always wins, because humans are lazy. Mozilla tried for years (and failed) to match that ease of development, and then decided XUL is not a hill worth dying on - especially considering how it also held back a lot of performance-related improvements.
As others have said, it will hurt but it's worth doing if the browser is to survive. It would have probably come sooner had it not been for the FFOS distraction. Once the ecosystem is fully rebased on webextensions, then Mozilla can try an embrace-and-extinguish play if they really want to.
the same people who are most vocal about this are the same people that are most vocal about not having multi process support and about having compatibility issues with extensions when the browser updates or when one extension steps onto another extension (all old-style extensions share a single namespace).
Web Extensions are designed in such a way that these issues can go away.
Apparently Mozilla weighs the complaints with regards to missing multiprocess support and addon security issues higher than they weigh the complaints about the old extensions going away.
I wouldn't call this decision "bonkers" either as, clearly, adding security is more important than keeping the platform stuck in the past in order to keep addons used by a minority of users working.
Web Extensions are designed in such a way that these issues can go away.
Apparently Mozilla weighs the complaints with regards to missing multiprocess support and addon security issues higher than they weigh the complaints about the old extensions going away.
I wouldn't call this decision "bonkers" either as, clearly, adding security is more important than keeping the platform stuck in the past in order to keep addons used by a minority of users working.
>the same people who are most vocal about this are the same people that are most vocal about not having multi process support and about having compatibility issues with extensions when the browser updates or when one extension steps onto another extension (all old-style extensions share a single namespace).
These strawpeople exist only in your mind.
These strawpeople exist only in your mind.
Selenium is fantastic for projects that need integration testing and enables to write ballpark tests.
Selenium IDE optimized our process that helped us save a lot of time.
Selenium IDE optimized our process that helped us save a lot of time.
The decision for Firefox to move to web extensions is stupid. The only reason I'm still using Firefox, which is technologically inferior (1) to webkit-based browsers are its high quality addons.
(1) Slower & crashes more, just more UX problems on websites all around (including youtube!).
And this Selenium thing is just another example of that.
You're really crippled in what you can do in Chrome. As a compulsive hoarder of bookmarks (about 2k last time I checked), it's important for me to have a bookmarks sidebar. Chrome doesn't have one, and it's not possible to add one via an addon.
(1) Slower & crashes more, just more UX problems on websites all around (including youtube!).
And this Selenium thing is just another example of that.
You're really crippled in what you can do in Chrome. As a compulsive hoarder of bookmarks (about 2k last time I checked), it's important for me to have a bookmarks sidebar. Chrome doesn't have one, and it's not possible to add one via an addon.
To expand further on Mozilla's ongoing commitment to WebDriver, we employ one of the editors of the WebDriver specification [1], are making significant contributions to the WebDriver testsuite, and are actively working on our geckodriver implementation to ensure that we have a fully-featured standards-complaint implementation as soon as possible. I also know that other vendors are working on improving the spec compatibility of their implementations, so I think the future of WebDriver is very promising, with fewer differences between drivers that aren't the result of fundamental differences in the browsers under test.
[1] https://w3c.github.io/webdriver/webdriver-spec.html