Firefox 55 and Selenium IDE

(seleniumhq.wordpress.com)

294 points | by slgt 2411 days ago

24 comments

  • jgraham 2411 days ago
    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 is the Selenium IDE which is a XUL extension that allows writing selenium tests without writing any code. This is undoubtedly useful to some people, but as the original post says, there are alternatives in development that are targetting a similar niche, so the situation is not as dire as the title implies (I imagine the title is worded this way to reduce the number of duplicate bug reports that the Selenium owners have to wade through on the subject of Firefox 55+ compat. for IDE).

    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

    • romaniv 2411 days ago
      > 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)?

      • slgt 2411 days ago
        I am evaluating E2E Test Builder and Kantu Selenium IDE Light, both are Chrome extensions and open-source.
      • Geoff2 2411 days ago
        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

  • jph 2411 days ago
    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.

    • dbrgn 2411 days ago
      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?
      • simonstewart 2411 days ago
        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.

      • albertgoeswoof 2411 days ago
        This is not how capitalism works
        • confounded 2411 days ago
          Actually it is; there are subsidies for open source projects all over the VC funded technology industry.
        • 2bitencryption 2411 days ago
          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)!

        • oliwarner 2411 days ago
          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.

    • y0ghur7_xxx 2411 days ago
      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.

      • k__ 2411 days ago
        Are these E2E tests robust?

        I found they often break easily

        • y0ghur7_xxx 2411 days ago
          Yes they work. The only thing you have to watch out for is the timing for the assertions with

              .waitForElementVisible('[name="main"]', 10000)
          
          
          otherwise you sometimes check for a value in a field, but the field is not there yet, and the test fails.

          That's the only gotcha we found we have to be careful about.

        • my2ndaccount 2411 days ago
          Are these E2E tests robust?

          I found they often break easily

    • proustian 2411 days ago
      Have you tried Helium? https://heliumhq.com/
  • snowl 2411 days ago
    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?
  • Osmose 2411 days ago
    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?

    • neves 2411 days ago
      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.
    • pjmlp 2411 days ago
      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.

    • romaniv 2411 days ago
      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.
    • masklinn 2411 days ago
      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.
      • slgt 2411 days ago
        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 ;-)
    • z3t4 2411 days ago
      I didn't know this existed. I always write the tests in JS using .click() .focus() etc.
    • unexistance 2411 days ago
      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

    • 29052017 2411 days ago
      Fuck yeah
  • jackblack8989 2411 days ago
    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.

    • matt_wulfeck 2411 days ago
      Or the kind of engineers capable of contributing to the software.
  • danidiaz 2411 days ago
    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

    • slgt 2411 days ago
      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.
    • neves 2411 days ago
      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.
      • bshacklett 2411 days ago
        One could argue that bad or fragile tests can be more harmful than having no tests at all.
        • danidiaz 2411 days ago
          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.
      • mariusmg 2411 days ago
        >You just need to know when to use it

        When exactly is that ? Never ? That clusterfuck of generated code is useless.

    • romaniv 2411 days ago
      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.

      • danidiaz 2411 days ago
        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.)

    • camus2 2411 days ago
      > 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.

    • rgrieselhuber 2411 days ago
      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.

    • lesbaker 2411 days ago
      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.
    • fulafel 2411 days ago
      Sounds like app specific recorders could be more robust and resilient to changes.
  • fdim 2411 days ago
    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.

  • hardwaresofton 2411 days ago
    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?
    • simonstewart 2411 days ago
      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....

      • hardwaresofton 2411 days ago
        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.

    • neerajdotname2 2411 days ago
      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.
      • chinathrow 2411 days ago
        Your site says "Run tests in Chrome, Firefox, or in IE 11" - so is that claim still true or am I missing something?
        • neerajdotname2 2411 days ago
          We need to update homepage along with all screenshots since all screenshots with Firefox are outdated now.
      • albertgoeswoof 2411 days ago
        Chrome is the new IE
        • reitanqild 2411 days ago
          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)

      • Vinnl 2411 days ago
        But that has nothing to do with the IDE no longer being available, but merely as a cost-saver for you guys (I presume).
    • Vinnl 2411 days ago
      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.
  • t0mbstone 2411 days ago
    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?

    • pjmlp 2411 days ago
      > 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.

    • toyg 2411 days ago
      > 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).

  • sambe 2411 days ago
    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.
    • nallerooth 2411 days ago
      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.
      • sambe 2411 days ago
        I didn't mean to imply people are surprised. They have made the decision regardless of the amount of notice.
  • rdiddly 2411 days ago
    Maybe instead of "will not be fixed" the headline should say "contributors needed?"
  • slgt 2411 days ago
    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).

    • tw21 2411 days ago
      This extension uses the Webapi... so I assume it can be "backported" to Firefox?
  • 8114Y 2411 days ago
    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.
  • fulafel 2411 days ago
    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.

    • flukus 2411 days ago
      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.

  • Aardwolf 2411 days ago
    Might it still work in SeaMonkey? Unless SeaMonkey also plans to change the extension mechanism...
  • bertolo1988 2411 days ago
    Why would they maintain it? Browsers are providing headless ways to accomplish the same.
    • foota 2411 days ago
      The selenium IDE is a tool that records actions done in the browser for replay, not the test driving component.
  • brian_herman 2411 days ago
    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.

  • blubb-fish 2411 days ago
    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?

    • simonstewart 2411 days ago
      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.
      • blubb-fish 2411 days ago
        sure - but this might very well indicate a trend.
        • blubb-fish 2411 days ago
          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.

          • nirvdrum 2411 days ago
            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/

          • MikusR 2411 days ago
            • blubb-fish 2411 days ago
              pretty generic, I'd say ...
    • rmetzler 2411 days ago
      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...

  • sweep3r 2411 days ago
    This is what is going to happen to most extensions. Mozilla is bonkers, doing this. They're going to regret it.
    • Animats 2411 days ago
      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...

      • Vinnl 2411 days ago
        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.

        • quazeekotl 2411 days ago
          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.

          • Vinnl 2411 days ago
            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.

            • moosingin3space 2411 days ago
              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.
              • quazeekotl 2411 days ago
                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.

                • Animats 2411 days ago
                  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.

      • clarry 2411 days ago
        > 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?

      • naibafo 2411 days ago
        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.

    • mixedCase 2411 days ago
      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.

      • Grue3 2411 days ago
        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.
        • ohthehugemanate 2411 days ago
          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.

          • aorth 2411 days ago
            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...
          • nindalf 2411 days ago
            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.
          • tw21 2411 days ago
            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.
          • sweep3r 2411 days ago
            Firefox is way faster than what? IE6?
            • sgift 2411 days ago
              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.
              • quazeekotl 2411 days ago
                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.
                • seba_dos1 2411 days ago
                  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.
            • jsudhams 2411 days ago
              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.
        • sethhochberg 2411 days ago
          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.

          • nindalf 2411 days ago
            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.

            • seba_dos1 2411 days ago
              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 :)
      • sweep3r 2411 days ago
        >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.

        • walterbell 2411 days ago
          Forks (or old versions of Firefox + extensions) can be run in isolated VMs on platforms like Qubes.
          • 4c2383f5c88e911 2411 days ago
            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.
            • walterbell 2411 days ago
              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.
              • testestx 2411 days ago
                This is totally impractical, or people would be already doing this when using other browsers as a defense in depth thing.
                • walterbell 2411 days ago
                  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.
    • toyg 2411 days ago
      > 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.

    • pilif 2411 days ago
      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.

      • quazeekotl 2411 days ago
        >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.

    • 29052017 2411 days ago
      Bhag bhosdike
  • my2ndaccount 2411 days ago
    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.

  • mememaestro 2411 days ago
    abandon all hope ye who is a web dev
  • 29052017 2411 days ago
    Bhenchod yeh hai kya
  • norswap 2411 days ago
    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.