Hacker News new | comments | show | ask | jobs | submit login
Firefox 57.0 Released (mozilla.org)
1691 points by l2dy 8 days ago | hide | past | web | 813 comments | favorite





I just updated - WOW! What an improvement! Compared startup time and scrolling around some over-monetized sites; Behaves just as well as Chrome. Time for a switch again, I've missed FireFox since I started having Chrome as my default browser back in ~2011

I find the bit about Chrome interesting, considering I've never had a Chrome installation even without any kind of add-on that was as fast as FF Quantum. Even without any features at all Chrome is much slower and it doesn't even have proper extensions for most things.

On Linux, its still night and day difference in favor of Chrome.

I wish FF performance was as good as it is on Windows.

As much as I want to like Mozilla, even with Quantum, there's pretty much no hardware acceleration at all, missing out on potentially big performance benefits.

As others mentioned, e.g. VDPAU has been available for a long time now and there's no excuse for not taking advantage of GPU acceleration.

Now contrast this to evil Google and Chrome.

Firefox: https://imgur.com/mvtDenC Chrome: https://imgur.com/HBOpucc


For me it's exactly the opposite. While js and render performance might have been worse, scrolling has become more and more choppy with every chrome release while Firefox has absolutely no issues (even without quantum)

There certainly is hardware acceleration in Firefox on Linux, more then likely it has been disabaled because of your configueration/set-up/drivers. To turn it on go into your "about:config" and toggle the entry "layers.acceleration.force-enabled" to "True" and restart. Then Firefox is as fast as Chrome or faster, simple as that. Although it would be nice if there was a dialog telling the user their setup is incorrect/unsupported and giving them the option whtout digging into the config, I believe this is the number one reason people think FF is slower, cause their HW acceleration is disabled and they don't even know it is...

>There certainly is hardware acceleration in Firefox on Linux, more then likely it has been disabaled because of your configueration/set-up/drivers. To turn it on go into your "about:config" and toggle the entry "layers.acceleration.force-enabled" to "True" and restart.

Implying that it wasn't deliberately disabled. HW acceleration on Linux isn't enabled by default, and for good reason. Until those underlying reasons are changed, Linux does have a hardware-acceleration-on-Firefox problem.


Are there any articles that elaborate on what work still needs to be done?

yup.. enabled this option on Linux Mint 17.1, FireFox 51 .. crashed the nouveau driver 10 minutes later.. had to restart.

FF 57 is the first release of a big rewrite, I'm sure it will get VDPAU at some point, but they needed to get the base feature set stable first.

It looked great, up to the point that 70% of my addons were disabled. I rolled back in 5mins :)

I'll give it another chance in a couple of weeks, and hope that there will be a bypass that will force my outdated addons to work.


There won't be a bypass - Fx57 has completely dropped legacy extension support.

This is a good thing, and it's just a shame that so many addons haven't been updated yet.


This isn't quite true. Support for legacy extensions is disabled by default, but can be re-enabled via the `extensions.legacy.enabled` flag in about:config.

Don't expect it to work very well, though, given that a lot of the supporting code for legacy addons was already removed from Gecko 57.

Huh, thanks for mentioning that! I didn't realise there was still a flag for it - serves me right for not doing my research.

Though losing Electrolysis will defeat one of the main benefits of running Firefox 57...


Though you lose multi-process operation, I think....

only on incompatible MP plugins.

however I've just ran nightly and although it says vimfx will work as a legacy plugin it's not working, so the deal's off. I shall not use my mouse!


You can try vimium-ff (FF 57-compatible). There is also Tridactyl [1] currently in development.

1: https://github.com/cmcaine/tridactyl


Only in Nightly.

So while I'm still waiting on NoScript to get an update which is actually forthcoming (possibly tomorrow, but within about a week from what I gather), I took a look around to see which of my other add-ons were updated.

Other than a couple that were useful but ultimately not that important, and a couple I can do without until they get updated eventually, I managed to find that most of my Legacy extensions do have updated versions out. Namely, Video DownloadHelper and Greasemonkey, both extensions I thought would die with Firefox 57 out. That said, I wouldn't have known if I hadn't looked at the add-ons site as near as I can tell, while they still say "Legacy" in my Add-ons tab, they do have separate releases on the add-ons site specifically for Firefox 57 which are incompatible with my current browser and I'll probably have to install them again when I do update.* Assuming that is the case, you might find a decent chunk of that 70% already ready and you just have to take some extra steps to get them working again.

Overall, I am optimistic, lots of people have lots of nice things to say about 57 and the extensions situation is not looking nearly the sort of bad I was first expecting. I'm sure I've had more painful wait periods for my extensions going back almost a decade ago as it seems I really am waiting on just one and that one is coming shortly. Even those extensions which are now unsupported actually seem to have decent replacements and I've switched them over already.

* Note, this portion is entirely speculative, refer back to my commentary on waiting till an updated NoScript comes out before I actually install Firefox 57. It's possible they would just update once I do upgrade to 57 rendering my subsequent speculation entirely wrong.


Greasemonkey will be updated from legacy to the compatible one automatically, no user intervention needed. I assume this holds true for all such extensions.

Yes, it is even better if you have a precision touchpad and you disable smooth scrolling. Whole new world of reactivity! It is almost as smooth as edge!

Whoa thanks for the tip! This is so much better!

If it as just as good as chrome, why should I switch? Especially given how good Chrome Dev tools are.

Aside from the privacy / philosophy / openness / counterweight-to-monopolization-of-the-Web angles which Yoric mentioned, you might find we're actually better than Chrome in some areas. Often small things, but I find I prefer the feel of Firefox to Chrome.

- If you do frontend work, our CSS grid inspector is unparalleled https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...

- Firefox has built-in tracking protection (https://nakedsecurity.sophos.com/2017/11/12/firefox-to-offer...)

- Powerful add-ons like Tree Style Tab make managing large numbers of tabs much easier (https://addons.mozilla.org/firefox/addon/tree-style-tab/)

- Our WebAssembly performance tends to be better

- We should have better resource utilization when you have many tabs open

- You can mute audio on a page clicking the little speaker icon in the tab

If you want to contribute to the DevTools themselves, they're built using standard web technologies: HTML/JS, React/Redux, etc. https://github.com/devtools-html/


> - You can mute audio on a page clicking the little speaker icon in the tab

Although I don't know if chrome has this on by default nowadays as I turned it on so long ago.

But mute audio on per tab via speaker icon is available in chrome as well.

in chrome://flags/

* Tab audio muting UI control

If enabled, you can mute/unmute per tab via doing same thing.


Yes, it's been enable as default for a while now. But again firefox is awesome and the 57 version is simple blazing fast

Front end dev here. The main issue I have for now is that whenever I hit CTRL Shift C to open the console, you can clearly see the thing draw itself for nearly one full second. It would be fine if it somehow cached, but if you close it and open again, same delay.

Short of being able to optimize it soon, perhaps you could try buffering and displaying it at once. It would look less clunky and flimsy.

That said I'm giving FF57 a run as my main browser, will keep using Chrome Dev Tools for now.


> - Firefox has built-in tracking protection (https://nakedsecurity.sophos.com/2017/11/12/firefox-to-offer...)

Is there a way to selectively unblock certain trackers on a specific page?

I currently have the Tracking Protection set to Always and the block list on Strict. No problems yet, but I know there will be a few sites which won't correctly. Previously I always used Ghostery and there was a nice option to view exactly how many and which trackers were being blocked on each page. When viewing the blocked trackers, they could be selectively unblocked one at a time if required. This was handy to make some embedded video work, without necessary enabling Facebook tracking, which would occur if the whole page was unblocked.


Take a look at the eff's privacy badger add on, which let's you control each script/source on a per-page level

Try umatrix.

You've switched to multiple processes model, but you don't have "task manager" as Chrome. Do you plan to implement it in the future?

Working on it right now, but no ETA yet.

Ok, thanks. I hope you make it even more informative than the Chrome's one :)

Please, that's one of the most useful troubleshooting tools in Chrome.

about:performance is a somewhat similar substitute for now. You can see stats of the various processes and close or reload tabs.

Yes.. Somewhat. For example can't see how extensions are doing from there.

especially TreeStyleTab is considerably weakend with the new update (like all extensions that now have to fit into less powerful webextension). From my point it is so bad (I lose 4 out of 6 regularly used add-ons) I am actively considering of leaving firefox for the better.

What do you use? Some things are still a bit hacky, but it all comes together for me. I had everything packed, ready to move, but than came the ports :)

To be honest I have not switched yet, but the changes I have seen in TreeStyleTab make me question why I should stay at firefox with that because I can get the features of the new TST in Chrome as well. Also I won't work with Colorful tabs anymore. Further I think I will miss some of the decapriated features in the Zotero update.

(And I will have to find appropiate replacements for Leechblock and FireGesture)


Leechblock is updated. The developer made it into a separate add-on though.

https://addons.mozilla.org/en-US/firefox/addon/leechblock-ng...


What "TST in Chrome" are you referring to? Tree-Style Tabs are one of the main things that keeps me using Firefox over Chrome. All of the Chrome Tree-style extensions that I have tried are these hacky things that use an external window.

I tend to use Chrome for its devtools, but I'd add WebRTC support to the list of things Firefox excels at

It also has toolbar RSS feed support. I've been using this since when Firefox was in beta (Phoenix) and it's a killer feature for me. I may use Feedly on iOS but desktop/laptop I love having the same feeds right on the toolbar. Chrome doesn't support RSS feeds in this way because there's no way to advertise with them.

Always watch where the incentives run, Chrome is for Google's best interests, not the web's and not the user's. Always has been and always will be because it's a for-profit organization.


> If you want to contribute to the DevTools themselves

I wish I had the time. So I'll have to wait for someone else to add the element DOM properties tab in thr panel that has the style rules and layout. Firebug had it, Chrome has it.

The right click and then Show DOM Properties with the results in the console pane is just painful to use.


Tree-style tabs won't be around much longer.

Tree Style Tab is available on Firefox Quantum and will be with us for a long, long time. Piro, the author, wrote an excellent article about his experience porting TST to a WebExtension: http://piro.sakura.ne.jp/latest/blosxom/mozilla/extension/tr...

Nice extension, but no search for tab option. For now I use Firefox built-in option to search for tab: open new one and start typing the title of tab, I want to find. The drawback: that search is VERY dumb and you have to exactly type the proper name, no fuzzy logic or smth at all.

I got the new Tree Style tabs installed, but I'm still seeing the standard tabs at the top, is there a way to hide those?

I asked this exact question on Stack Overflow earlier today and found that someone else had already also asked it and got an answer.

https://superuser.com/questions/1261660/firefox-quantum-ver-...

(basically, hacking some CSS rules by creating a file in your AppData directory, so that the top bar is hidden)

Incidentally, I also discovered that Tree Style Tab's settings page under Firefox has a nice little box where you can configure the CSS it uses, which was nice because I prefer it with a smaller font and less padding.


What uglycoyote commented is the stopgap solution for now, but an API for doing that is in the works, so in a few versions from now, you shouldn't need that more-or-less hack anymore.

Better privacy? Non-profit? More open source? Cheerful community? Pick one or more :)

Privacy is about the same, Mozilla Corporation (who distribute the browser) aren't non-profit, both are open source. Correct on community maybe.

The privacy situation is absolutely different; Mozilla has no profit motive to monitor and monetize your activity on the Web. For example, Firefox Sync is specifically designed so that we have no knowledge of your browsing data.

In contrast, when you sign into Chrome, "Your experience in other Google products is personalized by including your Chrome history with your Web & App Activity."(https://support.google.com/chrome/answer/185277)


> Mozilla has no profit motive to monitor and monetize your activity on the Web.

But if a substantial portion of Mozilla's funding comes from an organisation that does have a profit motive to monitor and monetise my activity on the web, then surely that's almost as bad (for me as the end user)?


There's a world of difference. For Mozilla to sell out on user's privacy it would mean game over. They simply can't afford to do so, even if they wanted to (which I believe they don't). Google on the other hand? That's their main business, they are an advertising agency. Sure they make nice products too but make no mistake where their profit is coming from.

I donate to Mozilla because they claim to support privacy, and I want them to be less dependent on large donations.

> Mozilla Corporation (who distribute the browser) aren't non-profit

Mozilla Corporation is wholly owned by the non-profit.

> both are open source

Not to the same degree, as Chrome != Chromium


> Privacy is about the same, Mozilla Corporation (who distribute the browser) aren't non-profit, both are open source.

Chrome is not open-source. Chromium is, but Chrome is not.


I personally like how it handles hundreds of tabs. No matter how many tabs I have open they remain usable size, and the compact UI theme is even more compact than Chrome.

Tab containers are useful for having multiple accounts on the same site (Gmail/Github), or isolating work or most secure sites from regular browsing. The containers are more light-weight and more general than Chrome profiles (and they don't depend on having external accounts).

Pinned tabs don't close on Command+W. It's a small thing, but I kept accidentally closing my pinned tabs in Chrome.

Chrome Dev Tools are hard to beat, although Fx is slowly catching up there, too. I don't mind launching Chrome just for web dev.


> No matter how many tabs I have open they remain usable size

They were! I think they've shrunk, though that might be an optical illusion... And I can't see a simple way to make them bigger (simple as in: not editing the css file).


There is a pref that controls the minimum width now (browser.tabs.tabMinWidth). The default changed from 100px to 76px in Firefox 57. You should be able to tweak this to change the minimum width.

Fantastic. Many many thanks.

A lot of us in the dev community feel that some of the web standards that Chrome is pushing does not reflect the will of the community at large. Chrome is also tied to a company known to have a business interest in data collection, while Firefox is maintained by the community with some funding from a nonprofit.

To support a non-profit, so that they actually have the might to fight for us.

because Google has the worst biz model in the tech industry and is doing harm to the world.

I think Chrome and its DevTools has positive overall effect on the world.

I guess you were not around during the Halloween papers then.

Or the Sco Linux lawsuits.


i was not. def slimy stuff.

How so? That's a pretty bold claim...

Fortunately brave rebels fight against this harm in every way they can :)

https://blog.mozilla.org/blog/2017/11/14/firefox-features-go...

The real world is not Star Wars. For all the privacy considerations etc., this comment above reads extremely naive.


Honestly, I find it to be (subjectively, I didn't actually measure anything) much faster than Chrome. At least, it feels much snappier on my MacBook Air.

Yeah, if it's just for the good of the internet, openess, and society, who cares to jump to an equal (but better at those regards) engine?

Becasue Firefox Dev tools are better ? I feel the Chrome dev tools more hard to use.

Now Google just needs to test their apps like Drive on it... I stopped using Firefox partly because they were so buggy on it.

If this were Microsoft in the 90s, everyone would be calling this anti-competitive behavior. Saying they're just buggy because they're not tested well is putting it much more nicely.

Same, and when you add script control with uMatrix it’s just perfect!

Firefox is pretty similar looking as Chrome now. I liked FF before cause it looked different, now everyone just copies Chrome look.

The dark theme looks much better than Chrome.

Does it? As a matter of fact, it's much more similar to MS Edge. With dark theme it's super close in terms of look. Rectangular, beefy tabs.

I'm not sure what you mean by "beefy". Do you mean the "touch" density with the very large tabs and icons? I'm on "compact" and it's very similar to Chrome except for the right-angled tabs. You can switch between three levels of density:

https://winaero.com/blog/wp-content/uploads/2017/11/firefox-...


While there are some similarities in the UI I don't think the photon design system is a chrome ripoff. http://design.firefox.com/photon/welcome.html

Hopefully most of the missing extensions will be developed sooner rather than later. I have 15 extensions installed, 14 of which are "Legacy".

The most critical one, Tree Style Tabs, has been converted. That was the key blocker that prevented me from seriously using Chrome. But many more remain; Cookie Controller, RefControl, some kind of Classic Theme Restorer equivalent (to get a menu bar back for Bookmarks, at a minimum), etc.


Have a look here [0] for legacy extensions replacements.

[0] https://docs.google.com/spreadsheets/d/1TFcEXMcKrwoIAECIVyBU...


There's no replacement for ScrapBook, a plugin where I have a decade of stored annotated documents (no hyperbole, my oldest files date from 2007). Ever since I discovered that FF57 was going to kill ScrapBook I had to disable Firefox updates so I don't lose access to ~6GB of stored data. It's a mix of past, present, and future writing research.

I know I have access to clumsy workarounds such as copying FF56 to a VM with updates disabled, or to have parallel Firefox installs, but Scrapbook is a daily-use tool for me, and clunky workarounds won't last long.

I'm thinking about reverse-engineering the way ScrapBook stores data so I can write my own migration to something else, but...oof.

Anybody have any suggestions for another plugin/product that offers the same features? Or, dare I dream, one that can import everything from ScrapBook? My searches for the latter have come up dry, but perhaps something obscure exists.


If you're on Windows, grab a copy of Firefox Portable ESR 52: https://portableapps.com/apps/internet/firefox-portable-esr

You can 'install' it anywhere you want (Documents folder, other drive, cloud folder, etc). You can copy your profile in using the steps outlined here: https://portableapps.com/support/firefox_portable#local_prof...

It will remain updated through April 2018 and your profile will stay separate from your installed copy of Firefox. In April, ESR is switching to a newer Quantum version of Firefox, so old extensions will be disabled. If, at that point, there isn't a suitable replacement for ScrapBook, disable updates in your copy of Firefox Portable (if you're using the PortableApps.com Platform to automatically update it, rename your FirefoxPortableESR folder to FirefoxPortableESROld or similar) and only use it for ScrapBook not to go online.


Scrapbook, that takes me back. Haven't used it in a dog's age. But I would be enormously surprised if it did no longer store saved content under your Firefox profile directory, and back when I used it, it just saved the files there and maybe did some link rewriting. Not really a lot of importing necessary to view the content outside the extension - you'd just need to point a browser at its file:// URL.

Not sure how much that helps in terms of retaining the actual functionality, which unless I'm badly mistaken would only be feasible in the WebExtensions API via the external application messaging interface - and you'd need a separate program that would receive those messages and do the mirroring for you, and maybe expose a local HTTP server or some other such horrible hack to let you fetch the content tree for rendering in the browser as a table of contents/tree of bookmark-style links. But at least you might not have to lose what you've got.


Today I spent some time looking at how ScrapBook stores information. It's a bit of a mixed bag, with some plain text files, some XML, some HTML (besides the saved pages themselves). I managed to figure out how it stores folder structure, bookmarks, saved pages, and annotations. Fortunately there's no database, and no encryption, so I can write a tool to extract the information if needed.

The remaining question becomes: how to replace it? What other tool supports all this?:

* Local saving (as opposed to cloud)

* Storing source URL with support for re-fetching

* Bookmarks (for pages that won't save locally in a useful way, such as YouTube)

* "Deep saving," saving the main page AND linked pages, and keeping them bundled together

* Full text search

* Probably other features I do not recall offhand

Even if I can get the data out, it's hard to know where to put it. Most solutions these days are cloud-oriented, which is unappealing to me. I could build my own stand-alone replacement, but what a headache. I could fork ScrapBook and try to make it work with the latest Firefox, but I have no experience in the plugin domain, nor the time to prioritize learning it.

Sorry for the rant, I'm just trying to figure out how to proceed without severe productivity loss.


I'd look at the Zotero standalone, but that's just an offhand guess. Other than that, I got nothin' - except 52 ESR, which is good for security updates until some time next year, and won't get the breaking changes from 57.

> I'm thinking about reverse-engineering the way ScrapBook stores data so I can write my own migration to something else, but...oof.

Looking around on the ScrapBook website[0] reveals that "gomita", the author of the plugin, has a GitHub profile[1]. Sadly without a repository of ScrapBook source code. Still, you could try contacting gomita and ask if they want to put it there to help with reverse engineering it? Or maybe even document how it works.

[0] http://www.xuldev.org/scrapbook/

[1] https://github.com/gomita/


Firefox extensions contain the source code anyways, find the "xpi" file, which is actually a zip file, unzip it, and explore.

Not to discourage asking for help, just that the source not being on github isn't super relevant.


Is the Web Scrapbook extension compatible with the files it generates? It seems to have a lineage (via Scrapbook X) that descends from ScrapBook.

https://github.com/danny0838/webscrapbook


Unfortunately, the answer is no.

https://www.reddit.com/r/firefox/comments/7btuln/so_long_and...

The Firefox team has specifically said they won't add support for the foreseeable future.

https://bugzilla.mozilla.org/show_bug.cgi?id=1246236#c113

More here: https://github.com/danny0838/firefox-scrapbook/issues/209#is...

Losing several hundred thousand users¹ probably isn't in the team's best interest; so hopefully they will make it a priority to revisit this, but I have a feeling there are resource limitations that will make this by design won't fix.

¹ https://docs.google.com/spreadsheets/d/1TFcEXMcKrwoIAECIVyBU...


I can relate to this, tho for me it was TiddlyWiki(-legacy), and UnMHT

you can use the ESR[0] release with the extension AND disabling auto-update, and use -no-remote paramater to run multiple instance FF...

So in your case, you can have two instance, one FF running ScrapBook, the other is new-and-shiny FF... I used this setup daily with multiple FF running at my whim, didn't feel clunky

p/s: ScrapBook sounds awesome, I myself did saves PDF version of website, where it still can be indexed/searched properly

[0] https://ftp.mozilla.org/pub/firefox/releases/


Not to my knowledge, but you can use the LTS version of Firefox. Which if I remember is still compatible with older plugins. It will be a year before Mozilla refreshes with the newer branch.

It won't last that long. The current ESR version of Firefox is 52. It will be switched to 59 at the start of March 2018, and 52 will be completely discontinued in June 2018. That's a little over 3 months until it becomes annoying to get a copy of, and a little over 6 months until it's dead.

https://www.mozilla.org/en-US/firefox/organizations/faq/


All prior Firefox builds are easily accessible via Mozilla's web interface to their FTP server at http://ftp.mozilla.org/pub/firefox/releases/ . For example, the latest FF52 ESR update for English Windows x64 is at http://ftp.mozilla.org/pub/firefox/releases/52.5.0esr/win64/... .

"Or, dare I dream, one that can import everything from ScrapBook?". Let's hope dreams are answered. You can add me to that probably long list of hopefuls who have huge records of online life in scrapbook for pre-57 Firefox.

It’s been a long time since I used ScrapBook. I don’t know about anything that can import from it either.

I wanted to suggest Zotero as a tool to capture information of different kinds. It’s a multi-platform tool that also has “connectors” (extensions) for different browsers. [1] It may probably not be a complete replacement for ScrapBook.

[1]: https://www.zotero.org/download/


The original Zotero also died with the demise of XUL extensions. It, too, used to be a Firefox extension.

Zotero can also be installed as a stand-alone application, independent of the Firefox version

At this point it would be best to start exploring other notetaking extensions and programs, like OneNote, Evernote, Zotero, etc. Now is the time to jump ship because from here on in it will get more and more unlikely that any viable bridges will remain compatible.

I did find this add on to convert Scrapbook files with a quick googlin' (no experience with it). Hopefully it helps. https://addons.mozilla.org/en-US/firefox/addon/scrapbookx-co...

The other option is to look at some of the PDF printing add ons because I remember a few supporting batch operations on scrapbook data. At least they did in 2010-ish.


Looks like a lot of wont be ported, limited functionality and lack of necessary APIs on that list. Doesn't quite give me much confidence in WebExtensions.

Note that the webextension APIs are still under active development. So just because the APIs don't exist yet doesn't mean that they won't ever.

> Note that the webextension APIs are still under active development.

In which case, switching to webextension support exclusively is premature at this point, don't you think? It would have been better to wait until the API was robust enough to allow 99.99% of legacy extensions to be ported.


Unfortunately, this would have meant no Firefox Quantum.

As a Firefox dev (I'm still working at Mozilla, although not much on Firefox atm), I have seen many, many occurrences in which I couldn't optimize codepaths, or even in some case fix bugs, because the old extension mechanism made it impossible.

Consider the necessary steps:

1. realize that an internal API is broken;

2. come up with a new non-broken API;

3. port all the internal code using the non-broken API;

4. add a compatibility layer between the broken API and the non-broken API;

5. check all the existing add-ons to find out which ones use the broken API;

6. hope you didn't forget any add-on;

7. attempt to get in touch with all the add-on developers;

8. repeat 7. many, many times, until you are sure that the add-on developers that do not respond have simply abandoned their add-on;

9. negotiate a transition plan with the add-on developer with whom you have managed to get in touch;

10. land the patch that you have written now 3-4 months ago;

11. maintain both the broken API and the non-broken API (and their tests) for ~1 year, until you are reasonably sure that all add-on developers who intend to migrate have done so;

12. maintain (and test) a downgrade path for people who switch between versions of Firefox;

13. finally land your code;

14. realize that you still have accidentally broken some add-ons and people are (rightfully) unhappy because "Firefox broke my add-on";

15. it's 18 months since you wrote your 2-lines patch, you can finally get rid of the dead code and tests and move to something else.

This was one of the reasons for which the Chrome teams managed to be faster and more efficient than the Firefox teams (well, that and a bazillion dollars to hire way more people). The add-on architecture is the main reason for which projects such as multi-processes only landed ~8 years after we had working prototypes and some other performance projects never landed at all.

So, yes, removing the add-on architecture is definitely painful for a number of Firefox users, but I believe that we could not postpone it any further, even if it meant that some useful addons could not be ported immediately. Also, for what it's worth, we have postponed it by something like 7 years already :)


I'm sure you'll hear a zillion complaints, but I really appreciate you folks doing this. I've been using a beta version for the last few months on one of my computers and it's so very much better. I can't wait to have it everywhere.

As long as you're here: I was told that the old extension API was way too broad, locking in a lot of design choices that were not really considered from the "do we want to maintain this for years and years" perspective. And that the new one is much more focused and considered. Is that the case?


(thanks :) )

> As long as you're here: I was told that the old extension API was way too broad, locking in a lot of design choices that were not really considered from the "do we want to maintain this for years and years" perspective. And that the new one is much more focused and considered. Is that the case?

Definitely. The old extension mechanism was basically "here is the toolkit we are using to build Firefox, come and plug anywhere/replace anything". If my memory serves correctly, at the time, Mozilla Browser/Firefox was (almost) the only browser doing any kind of extensions (I'm not counting M3 and a few experimental/academic browsers), so there was no real precedent on how to do this.

For a time, it worked extremely well. After all, much of today's Firefox is built from add-ons that were progressively integrated in the browser. And then, progressively, we realized that there were drawbacks to this "anything goes" approach, but we couldn't fix things because that would mean breaking thousands of add-ons.

So, after many years trying to postpone the inevitable for the sake of our users, we finally switched to a much better defined API. This WebExtension API is much smaller, much better documented, and does not expose internals-only stuff. Which means that now, we can fix internals-only stuff without breaking the API. Which should make the life of both Firefox developers, add-on developers and users much better :)


Thank you for your work on Firefox.

> This WebExtension API is much smaller, much better documented, and does not expose internals-only stuff.

It also doesn't expose a lot of stuff that's useful and not tied to Firefox internals in any way.

The browser is one of the most heavily used programs on people's computers. Integrating it with the rest of your system and workflow can have huge payoffs in user experience and productivity. The traditional XUL-based extension system, while not always pretty, allowed for that. WebExtensions are severely lacking here and some of that seems by design.

As an example, I'm still trying to figure out a non-insane way to implement something akin to the It's All Text extension that allows editing text areas on websites using a proper text editor.


As a fellow fan of It's All Text, I've looked into this a little bit, though I never got around to implementing anything. You're looking for the "Native Messaging" feature: https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Na...

I just checked the It's All Text github repo, and their suggested replacement is a thing called GhostText¹, which actually seems a good deal fancier that IAT ever was.

¹: https://github.com/GhostText/GhostText


Looking at GhostText and its editor integration scripts, those basically work by running a websocket server on localhost. Implementing access controls seems to be left as an exercise for the reader.

If I understand the native messaging API correctly, nothing in there requires the presence of any networking daemon. The browser just execs a program you can communicate with using JSON messages on stdin/stdout. That is already a lot better than I thought.


I tried that, too. There is no such method at this time that doesn't involve setting up something in between the browser and the editor to marshal between the browser's native messaging API [1] and the editor's desire to operate on text files. I don't think that's insane at all, but the complexity involved did exceed my frankly passing desire to get IAT back - I barely ever use it any more. It shouldn't take a reasonably experienced extension developer more than a day or so to implement, though, I would think.

[1] https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Na...


I believe IE also had extensions (the channel bar in Windows 98, and later toolbars and ActiveX that partly lead to Firefox becoming so popular). It certainly didn't have as much flexibility as XUL though!

That's possible. ActiveX was powerful but... problematic :)

Oh yes! It very much is :)

I hate to be the person to say this, but perhaps a better approach would have been to simply create a build pipeline that iterated over the addons on AMO to find the ones that use functions from the changed API and bulk send out an email about the changes to the authors (this eliminates steps 5 through 8). The addon developers then get the chance to change it or not. If it's broken oh well (eliminating steps 8 through 15). Making it the responsibility of the FF core team to sit on changes while waiting for a reply is a procedural problem not a problem with XUL/XPCOM. Moving to Web Extensions, which fundamentally make it impossible to access the full file system, permanently breaking many useful addons with no functional way to migrate to FF57 and calling that better is frankly dishonest.

> I hate to be the person to say this, but perhaps a better approach would have been to simply create a build pipeline that iterated over the addons on AMO to find the ones that use functions from the changed API and bulk send out an email about the changes to the authors (this eliminates steps 5 through 8).

This would have automated steps 5 through 8, but not significantly reduced the problem.

> The addon developers then get the chance to change it or not. If it's broken oh well (eliminating steps 8 through 15).

Ah, well, sure, in that case, randomly breaking add-ons all the time would indeed have made our life easier. But everybody else's life would have been much worse, so we decided not to do that :)

> Making it the responsibility of the FF core team to sit on changes while waiting for a reply is a procedural problem not a problem with XUL/XPCOM.

It's a problem of the combination of having no API (i.e. XUL/XPCOM) and not wanting to break user's add-ons.

> Moving to Web Extensions, which fundamentally make it impossible to access the full file system, permanently breaking many useful addons with no functional way to migrate to FF57 and calling that better is frankly dishonest.

Let's just say that we have different priorities. While it's not as powerful, it's better for security, performance, privacy, bugs and future-proofing.


>Ah, well, sure, in that case, randomly breaking add-ons all the time would indeed have made our life easier. But everybody else's life would have been much worse, so we decided not to do that :)

but you did exactly that

>Let's just say that we have different priorities.

seems so, your priority became... trying to speed up hoping that people too dumb to care would switch back from chrome despite it's horrendous and unethical marketing while sacrificing everything that made your browser viable


> Ah, well, sure, in that case, randomly breaking add-ons all the time would indeed have made our life easier. But everybody else's life would have been much worse, so we decided not to do that :)

This is the part that I think you are going to get the most flak for. People are willing to deal with temporary setbacks if the changes can be brought in at some point. Permanently breaking things and calling that better will get the Mozilla Foundation a mountain of angry hate mail from people who committed to the platform.

> Let's just say that we have different priorities. While it's not as powerful, it's better for security, performance, privacy, bugs and future-proofing.

I have no problem if the Mozilla Foundation or the Firefox team has different priorities, but say that rather than telling technical people the reason for the changes is because XUL or XPCOM are somehow so hideous the team had no choice. It smacks of dishonesty when everything that you have described here is a problem with procedure not anything technical.


> I have no problem if the Mozilla Foundation or the Firefox team has different priorities, but say that rather than telling technical people the reason for the changes is because XUL or XPCOM are somehow so hideous the team had no choice. It smacks of dishonesty when everything that you have described here is a problem with procedure not anything technical.

Well, some of our priorities with WebExtensions are (not necessarily in this order):

- stable, documented, future-proof API;

- improving security;

- improving performance;

- improving privacy.

You are, of course, free to consider these things "not anything technical", but they were impossible as long as add-ons weren't based on an API at all.

So, again, while I fully realize that there is a cost, I believe that we're moving from something unsustainable to something sane, which makes it better in the long run.


> I believe that we're moving from something unsustainable to something sane

It is only unsustainable because the FF team chose to make the process more difficult than it had to be. This is how what you are saying sounds:

1. We didn't want to break plugins so we involved addon developers

2. The process takes so long that it takes 18 months to introduce any new code

3. Since 2 was so slow we decided instead we would PERMANENTLY break plugins with no way to ever fix them

Put another way: things were taking too long because of Mozilla's own self-imposed guidelines so the Firefox team had no choice but to PERMANENTLY break addons that will never be fixable by design because the Firefox team was so concerned about temporarily breaking plugins. This is double speak. The predicate (3) contradicts the subject (1).

After it was pointed out how ludicrous this sound the caveat is added that this had to be done in the name of security, performance, and privacy. At what point did security and performance become more important than an open platform and why? Numerous addons exist solely to provide privacy by blocking fingerprinting, stopping redirects, providing control over cross-site requests (RequestPolicy Continued), super-cookie safeguards (BetterPrivacy), and these options are no longer available. How are these privacy enhancing features being added now that the option has been removed since the goal is privacy?

The whole thing is hard to take at face value when everything seems to be self-contradicting (sans performance).


Looks like we're both running out of arguments, since we're both essentially repeating ourselves, so I'm going to admit that I'm not going to manage to convince you :)

Have a good day.


I am not trying to be hard on you. I know you likely don't have any real say in the process, but as one of the senior developers at the Mozilla Foundation you have an opportunity to call out shenanigans when you see it.

First we hear the changes are because adding new code took too long because the team didn't want to break addons, yet WebExtensions does just that in ways that are far worse than just temporarily breaking addons.

Second we hear it's about privacy. Yet WebExtensions breaks a large number of privacy plugins that won't be ported. There is also the Cliqz partnership and the October experiment. "In August 2016, Mozilla ... made a strategic investment in Cliqz. Cliqz plans to eventually monetize the software through a program known as Cliqz Offers, which will deliver sponsored offers to users based on their interests and browsing history."[1] "Mozilla is experimenting with including the Cliqz plug-in by default in its open source Firefox browser."[2] The reader can decide for themselves whether or not this is in the interest of privacy.

All that is left then to explain the changes are possibly security and speed. Security I am not so sure about as privacy and security tend to go hand in hand. It would be nice if you could respond to the earlier questions. FF57 is noticeably faster however so that is at least believable.

Whatever the real story is I do appreciate you engaging with us because you have no obligation to be here and you deserve respect for that.

Stay well David, hope you have a good day too.

[1] http://archive.fo/zjf8a#selection-319.2-323.243

[2] https://www.htmlgoodies.com/daily_news/mozilla-experiments-w...


I have to agree with this.

If you provide an API you'd better commit to it.

A lot of work is being wasted because of this.

"Do not break userspace".


Indeed, if you provide an API you'd better commit to it. The difference is that before WebExtensions, there was no API. Everybody was just hooking into the internals.

That's not "do not break userspace" – which makes sense – that's "do not change anything, ever" – which is project suicide.

Now, with WebExtensions, there is a difference between the API and the internals, so we can commit to something. And, while there is a cost to this change, that's definitely a much, much, much better base for developers on both side of the API.


Mozilla pitched the Add-on SDK to developers as that kind of API. It was deprecated less than a year ago with no migration path and a half-baked replacement.

The browser internals aren't userspace. Web Extensions are userspace. The browser internals are more like kernel space, which the Linux kernel breaks, all the time [1].

[1]: https://github.com/torvalds/linux/blob/e7aa8c2eb11ba69b1b690...



Sure, to be pedantic about it, but the point of "not breaking userspace" is not a technical nitpick on browser extensions.

It's the guideline from Linus and for a good reason. It's impossible to base work on shifting sands.


Many thanks for this informative post. I’ve read quite a few of the official Mozilla communications (announcements, blog posts, etc.) and so far, this has been the best explanation I’ve read for the impetus to move from XUL-based add-ons to WebExtensions. I write this from the perspective of a user who will lose almost half of their current extensions when they upgrade to 57.

Thanks :)

(and sorry about your extensions)


Also by moving ahead you are making the platform more valuable to get authors of plugins to come back and develop upon.

Ignore the naysayers. Thank you for this. I've been dodging legacy add-ons already because they like to interfere with multi-process mode, killing Firefox's performance. Ubuntu's crappy legacy add-on actually nearly made me dismiss Firefox out of hand when I first gave it another try in February.

I know it's not really the subject, but since you work at Firefox: Is Thunderbird still actively developed? Or basically on life support?

I'm sure you're absolutely correct in all the above, but I was happy with Firefox 56, then you broke mouse gestures so I stopped using Firefox and switched to Vivaldi. Whether alienating a huge number of formerly content users ends up increasing Firefox marketshare remains to be seen. But I won't be one of them.

Did any of that require destroying the usability of the UI?

The right thing to do would have been to work on those extensions BEFORE breaking users' experience.

Mozilla doesn't create all those extensions.

And the extensions' authors had, what, two years advance warning or so?

Criticize the real culpits, not Mozilla.


There's only so much an extension author can do if WebExtensions doesn't expose an API corresponding to one which was critical in the XUL extension.

I'm in that position myself right now, having volunteered to take over Firemacs development before I found that there is no way to listen for keypress events in browser chrome. You can only do that in injected content scripts, which don't work except in web content and are also affected by CSP. Until that changes, there's nothing that I, or the Vimperator developers for example, can do to provide an acceptable user experience.

It's super frustrating, and I don't blame users of such extensions for being angry about the indefinite lack of a future for them. But I also don't really blame Mozilla for prioritizing the implementation of the necessary APIs below other tasks which are important to a larger fraction of the Firefox user base.


Have you engaged with the WebExtensions team to help develop a new API that would suit your use case?

No, because the Vimperator crew had already done so, and what solves their issue will also solve mine. Otherwise I would have.

As a Mozilla dev, I fully support the move to WebExtensions, but I also disagree with you.

Porting an add-on to a whole new architecture is lots of work. People who do this on their spare time, or small companies, or companies relying on contractors, may not have the time/resources/will to do it, even within two years. Also, in some case, the APIs are simply not available.

As for why I believe that the move to WebExtensions was necessary and could not be postponed further, I have written a few lines in another thread: https://news.ycombinator.com/item?id=15695854


Sure, but what I'm arguing against here in this thread is the pervasive "Mozilla is evil, they only killed XUL extensions for fun". Just read this thread.

When actually millions of users get a vastly superior Firefox. Many, many extensions have been updated. And some extensions – mostly niche ones haven't. I love that trade-off.


On this, I definitely agree.

The point of your post on which I disagree is the idea that we need to name a "culprit".


Parent started blaming people. I certainly understand when authors don't have time or have lost interest.

Insofar I was wrong. It's not authors who are to blame, it's very vocal users. You can see a few of them right here.


If the required WebExtension APIs don't exist (per nicoburns' comment) I'm not sure what you want the extension authors to do about it.

"Complain loudly" was the strategy that got Mozilla to implement Tree Style Tabs as a WebExtension feature so that the addon could be rewritten for FF57, but there are presumably still legacy extension capabilities that haven't gotten that treatment.


Look at this from a user perspective:

The user diligently updates Firefox, optimistically hoping that this new version will be as awesome as the previous ones that vastly improved performance. Firefox starts and, suddenly, a bunch of things that used to work stop working.

Why?

Well, essentially, something that they can't hope to comprehend and that they never asked for and had no input on just ruined their browser.

What do you think they are going to conclude? That extension developers are to blame?

Nope.

Their conclusions are going to be something along these lines:

"Those idiots (Mozilla) broke Firefox... again"

"Firefox 57 is a buggy piece of Turd"

"I'm tired of dealing with this shit. I'm switching to Chrome"

Users won't blame the extension developers. They will blame Firefox.

Mozilla should have done a better job with this transition. "Upgrading" an extension to use the new API requires a complete rewrite, AFAIK.

It is TOTALLY unreasonable to expect that a bunch of developers - who probably are doing this for free - are going to be able to quickly migrate their extension to the new API - especially considering that the API isn't even stable yet, and is missing a ton of functionality.

This is the mother of all breakages. Mozilla should've tried to smooth this transition, not just simply pull the pin on the web extensions grenade and yell "Catch!".

They screwed this up big time. Time will tell what this will do to their ever shrinking market share.


> Users won't blame the extension developers. They will blame Firefox.

What's funny to me is that these 'users' you describe are apparently on HN - I thought this place was mostly software devs, but it's striking how many posts seem to fundamentally misunderstand the decisions made by Mozilla.

> This is the mother of all breakages

I would be that somewhere above 90% of FF users will be unaffected. Given Firefox's market share that's still a lot of people, but let's not pretend like they broke everything overnight.

> Mozilla should've tried to smooth this transition, not just simply pull the pin on the web extensions grenade and yell "Catch!".

You're implying that this was an unexpected change that Mozilla was not forthcoming about. It is the opposite. We've all known about this for months.

The value prop of no longer being tied to an extremely old system is significant and you're not giving it any of its due credit.


>We've all known about this for months.

Years, in fact.


The users' perspective, in short: before 57, I had one browser that was fast but lacked all the UI tweaks that I had grown accustomed to over the course of a decade or so (Chrome/Chromium), and one browser that maybe wasn't so fast but had all those UI tweak (Firefox, which I used all the time).

Now I have not one but two fast browsers with a UI that I do not like.

It's perfectly understandable that Firefox devs would love Firefox to be more like Chrome, but that has nothing to do with what the (existing) users want: they already have Chrome available, they are not holding their breath waiting for Firefox to become Chrome.


Thank you, your post perfectly encapsulates my feelings on the matter.

> "I'm tired of dealing with this shit. I'm switching to Chrome"

That was already happening, where "this shit" was crippling performance issues, and a lack of sandboxing and modern security features.

I expect Mozilla believed that the user fallout from breaking some extensions would be less than the existing continuing fallout of the ongoing issues.

> Mozilla should've tried to smooth this transition, not just simply pull the pin on the web extensions grenade and yell "Catch!".

You do realize that this transition has been going on and has been publicized for years, right?


1) Mozilla isn't retarded. They've done market research on this.

For example, in Sep. 2015 around 40% of users did not use any extensions at all. Another sizeable number of users is going to have their ad blocker and nothing else. Even with 2, 3 or 4 extensions, it's unlikely that you're going to experience a breakage, and if you do, it's likely that you'll find a replacement.

Average users rarely use unpopular extensions and popular ones either are maintained or will have a replacement made. There are some semi-popular ones that currently can't yet be fully recreated, but those are the types of extensions that change so much about the browser that average users won't be using them anyways.

2) Users aren't retarded. I know, we like to act like they are, but only the most cynical are going to switch browsers, because of this. Out of spite. It does not make any sense to switch to a different browser, just because the browser that you're used to has become different. Nor does it make sense to switch to Chrome, which is still by far less extensible than Firefox 57, just because Firefox has become somewhat less extensible.

3) The core of the API is more than stable. It's Chrome's extension API, that's been battle-tested in Chrome for years. Most extension developers will not need more than that. And it's most definitely not missing a ton of function, especially not things that non-power-users need.

4) Their market share is not anymore shrinking. It's been growing again since the release of Firefox 48. That was the release which shipped the first iteration of multiprocess. They could not have shipped multiprocess as early as that, if they did not know legacy extensions to be deprecated now with 57. Because the majority of legacy extensions are not multiprocess-compatible and neither would have been updated to be.

AMO would be reverse Russian Roulette where only roughly 1 out of 6 extensions will not kill your performance. That's just as well something you can't expect average users to understand and it would be like that for the next few years still.

So, yeah, they did rush this, but it was to save their market share. Had it continued to drop like in the half year before Firefox 48, we'd now be deep into negative user numbers.


> Even with 2, 3 or 4 extensions, it's unlikely that you're going to experience a breakage, and if you do, it's likely that you'll find a replacement.

This is simply not true as there had been many popular UI-centric extensions that just can't be replicated as webextensions due to lack of API support. "Advanced UI features belong in extensions, not in main" had been the Firefox mantra for many years and negativity about 57 is the logical consequence.


Which are the type of extensions that change so much about the browser that average users just won't use them.

When I discovered Classic Theme Restorer, Tab Mix Plus and similar, I was already a semi-pro user and I still found them intimidating.

There were a lot of checkboxes and they changed around a lot of things and I didn't yet know how to create a separate Firefox profile where I could've actually just wildly tried different options without the fear of something breaking irreversibly.


the only plugin that broke for me was NoScript and I switched to uMatrix which I like even more. i'm not exactly a firefox power user i guess but i am a web developer who is definitely an advanced user, and i was barely affected by this.

If required APIs don't exist any more, how is that extension author's fault? (Tab Groups user here)

If they don't exist, sure, but most of the bickering is "I want XUL and nothing else".

And how many of those lamenting the absence of some API have actually told Mozilla what they need?

By all accounts Mozilla has been very responsive and helpful. Not everything was possible, but the problem lies mostly not on their side.


> most of the bickering is "I want XUL and nothing else"

I don't know that that's fair. The discussions I've seen and participated in have revolved around equivalency, not identity.

> how many of those lamenting the absence of some API have actually told Mozilla what they need?

The Vimperator devs and some users have been very clear on that point.

> Mozilla has been very responsive and helpful. Not everything was possible, but the problem lies mostly not on their side.

Mozilla has indeed been responsive and as helpful as they can be given the constraints under which they operate. But extension developers aren't really to blame here either, because if WebEx doesn't include an API you can use to do what you need to do, then what option do you have? There's frustration on all sides - Mozilla devs, extension devs, and users. But we're all pulling together toward the same ultimate goal. I don't know what improvement anyone expects to elicit by trying to assign blame.


> I don't know that that's fair. The discussions I've seen and participated in have revolved around equivalency, not identity.

I've developed a couple of Firefox extensions. One of those was an e10s-compatible replacement for Vimperator, because Vimperator relied on XUL[0]. (Vimperator broke long before Firefox 57, because e10s broke backwards compatibility with some extensions long before Firefox 57 did).

The old extensions "API" was essentially a way to plug into arbitrary parts of the Firefox codebase. A Firefox developer has previously said that "[previously] the entire codebase was our extensions API".

That's not scalable or maintainable in the long-run, and I would assume that any software developer who's worked on a moderately-large project would appreciate that allowing arbitrary entrypoints and coupling makes it impossible to do literally anything without breaking some part of that extremely ill-defined API.

It's really, really unfortunate that moving towards a modern approach to browser extensions meant breaking work that people had put in over the last fifteen years, but... there's literally no other way to do it. Firefox was the first non-experimental browser to allow browser extensions, and there are both benefits and costs to being first-to-market. In this case, the downside is that they ended up accruing this technical (maintenance) debt.

As someone who's written Firefox extensions that are no longer available due to the switch, I'm disappointed that this had to happen. But as a Firefox user, I'm much happier having Quantum and Electrolysis (e10s), and if the tradeoff is between those two directly, I'd choose Quantum + Electrolysis over those extensions.

Or, to put in XKCD form: https://xkcd.com/1172/

[0] https://github.com/ChimeraCoder/electrovim


By "equivalency" I mean having access to equivalent APIs for specific functionality, as for example the inability to listen for window events that's breaking Vimperator and friends. (And electrovim! Have you noticed that it stops working on chrome pages that don't run scripts? Has the CSP bug been fixed? I didn't think it had been.)

Maybe it's not possible to support window event listeners without breaking e10s. But I see no a priori reason why it should be.

I haven't seen anyone in a serious discussion demanding 100% XUL API compatibility or feature coverage. (For the purposes of this comment, most discussion of the issue on HN is unserious.)


The inability to listen to window events also screws over gesture extensions, which is my main sticking point right now.

"As someone who's written Firefox extensions that are no longer available due to the switch, I'm disappointed that this had to happen. But as a Firefox user, I'm much happier having Quantum and Electrolysis (e10s), and if the tradeoff is between those two directly, I'd choose Quantum + Electrolysis over those extensions."

Well, I'm a Firefox user, not an extension developer, and Pentadactyl happened to be one of the extensions that made using Firefox bearable. Now that it's permanently broken, I'll be moving to another browser which can offer a similar experience: Qutebrowser.[1]

[1] - https://www.qutebrowser.org/


> Well, I'm a Firefox user, not an extension developer, and Pentadactyl happened to be one of the extensions that made using Firefox bearable. Now that it's permanently broken,

Pentadactyl was all-but-abandoned for years before Vimperator was broken. It's been almost four years since it saw a release - which was for Firefox 24.0-30[0]. Its website still links at least three links to code.google.com on the front page! (I'm actually shocked if Pentadactyl has even been working for you until now, given that it was supposed to break a few release cycles ago - when e10s shipped - but maybe you just haven't updated Firefox in a while, or you manually disabled e10s.)

Vimperator - which is also incompatible with Firefox 55+ for the same reasons Pentadactyl is - at least has been receiving maintenance attention in the meantime[1], and also provides alternatives for use with Firefox 55+ (and 57+).

If you'd rather switch browsers entirely than use something like Vimium[2] on Firefox, go ahead, but it's hard to justify holding an entire browser back just to maintain compatibility with an extension that has been abandoned by its own maintainers. As I mentioned, I can't even reasonably expect them to hold Firefox back to maintain compatibility with the extensions I wrote and actively maintained. As a Firefox developer, I'm disappointed, but as a Firefox user, I'm more than happy enough with the changes to make up for it.

[0] http://5digits.org/pentadactyl/

[1] https://github.com/vimperator/vimperator-labs

[2] https://addons.mozilla.org/en-US/firefox/addon/vimium-ff/?sr...


Despite there being no official releases in years and being abandoned by its official developers, Pentadactyl was kept afloat by its users, from whom you could still get fixes and releases through google code and google groups. I also fixed some things for myself, based on help from the community. Despite all this, it did finally completely break recently (before FF 57), and I just had to not update FF for a while until I found an alternative. I used PaleMoon for a while, but now I'm switching to Qutebrowser.

"it's hard to justify holding an entire browser back just to maintain compatibility with an extension that has been abandoned by its own maintainers"

Pentadactyl was far from the only extension that Firefox decided to break. Many other extensions were affected.

As far as Pentadactyl itself went, the reason its maintainers abandoned it was because Firefox kept breaking compatibility with it over, and over, and over, and over. They understandably got frustrated by that and moved on to other things.

Then, when Firefox put their foot down and announced that they'd be changing the browser so that Pentadactyl will never again be able to work on it, no matter what its developers did, a lot of people didn't see the point of putting more effort in to. It survived only because of the dedication and help of the remaining community. Now there's nothing even they can do. Not with Firefox anyway. So we're moving on to something else.


you are a tiny minority and a specialized browser fork is a great solution for your use case in this situation.

I think that's a great point: it's difficult, near impossible, to make any particular piece of software contain 100% of the features that 100% of people want. Especially in the case of a tiny-minority feature, a specialized version that caters to your needs sometimes makes the most sense.

I just worry that people using some of these alternative browsers are opening themselves up to security issues since those code bases are less well-tested for security problems, and often they don't have the developer resources to implement things like process isolation and sandboxing.


> I just worry that people using some of these alternative browsers are opening themselves up to security issues since those code bases are less well-tested for security problems

Absolutely. The web browser is one of the most notorious attack vectors on computers these days. I find it hilarious that a vocal minority of power users is protesting this _massively impressive_ Firefox release just because they lost Tree Style Tabs or some extensions for downloading videos. Switching to a legacy fork like Waterfox or Firefox 52 ESR is not an enlightened move!


We lost NoScript!

Pentadactyl was the greatest browser extension ever created. I hope that something similar will appear in the future.

Well, I'm a Firefox user, not an extension developer, and I much prefer a performant browser with modern security features (and the ability to implement more in the future, which they couldn't do pre-57). I've lost a couple extensions during the move, but the tradeoff is well worth it to me.

And it sucks that you don't feel that way -- it really does -- but I suspect the vast majority of Firefox users feel as I do, and in the end Mozilla needs to cater to the most users possible.


electrovim is in no way a replacement for Vimperator. It's a couple of keyboard shortcuts. None of the current vim-like plugins for FF57 match what vimperator/pentadactyl can do. The problem I have isn't that they broke legacy things, it's that they broke legacy things without offering a path to rebuild them.

> electrovim is in no way a replacement for Vimperator. It's a couple of keyboard shortcuts. None of the current vim-like plugins for FF57 match what vimperator/pentadactyl can do.

Uh, yes, I'm the author of Electrovim, so I'm quite aware of the functionality that I was literally unable to implement because no equivalent API existed.

> The problem I have isn't that they broke legacy things, it's that they broke legacy things without offering a path to rebuild them.

Did you not read the rest of the comment, where I explain why there is no feasible way that they could have offered any path to rebuild them?


> I've developed a couple of Firefox extensions. One of those was an e10s-compatible replacement for Vimperator, because Vimperator relied on XUL[0].

Replacement for Vimperator implies it's, well, a replacement for Vimperator.

> Did you not read the rest of the comment, where I explain why there is no feasible way that they could have offered any path to rebuild them?

I don't see how your addressed that. Yes, existing extensions that used XUL would have to be rewritten using new APIs. My issue is that those APIs don't even exist. That there are good reasons the old APIs aren't available anymore doesn't address the lack of new APIs that offer anything near equivalent functionality.


Is it impossible to support window or otherwise chrome-level event listeners and also e10s? As I said in a prior comment, there seems no a priori reason that should be the case.

> Is it impossible to support window or otherwise chrome-level event listeners and also e10s?

Yes, because those things are now running in different processes, which means it requires IPC, and allowing extensions to communicate over IPC with the chome throws all the benefits of e10s out the window.


The Mozilla triage meeting in September, which covered this issue, suggests that the requested feature may land in Firefox 58: https://docs.google.com/document/d/1pw5y-GHwDLPV9bYK4HWCiZts...

It looks like it's been broken down into a number of separate issues since then, and there's some discovery yet to be done on how exactly the implementation will need to proceed - I feel like Firefox 58 is very optimistic, but I also feel like saying "this is never going to happen" is pretty premature at this point. At the very least, the Firefox devs don't seem to agree.


My browser and extensions did useful things yesterday that they do not do today. Who changed something in the meantime?

Obviously I paid nothing for Firefox and Mozilla owes me the same nothing in return, but if it wants to keep users and remain significant, breaking arguably its main advantage might not be the best plan.


If you're interested, I explained above https://news.ycombinator.com/item?id=15696184 why the switch was necessary.

As a Firefox user (and dev) I believe that breaking some extensions today in a clean manner that will let us maintain compatibility in the future is way prefereable than randomly breaking extensions with every single version of Firefox, as this has been happening forever. Plus this break has set us free to actually improve Firefox and make it competitive again, something I believe is in everybody's interest. I realize that it's painful for the users who lost some add-ons upon which they relied, but I believe that given the alternative, this was the best choice possible.


I was a software guy long before I was a web guy, so I completely understand the desire to clean up internals.

Unfortunately, as a user, the bottom line is still that if I update I will receive very little benefit and lose a lot of very useful functionality. It's not just the odd extension for me, it's things I use every day that are the most important reason I've stuck with Firefox.

I accept that I'm probably in a minority and that Firefox is going to go with what makes Mozilla money and pays the bills, which in turn probably means what attracts larger user demographics at the expense of the rest of us.

Mozilla in turn will have to accept, as I'm sure it does, that it's going to turn off power users and that it's going to prompt legitimate questions over why anyone would go with Firefox, even with these developments. The obvious alternative for most people, Chrome, already had the performance and architectural advantages, but previously lost out on flexibility and privacy concerns, and unfortunately Mozilla just surrendered a significant part of those advantages.


I can understand your point of view. I believe that better security, performance and privacy is worth the partial (and hopefully mostly momentary) loss of customization, but YMMV.

I hope time will prove you right.

FWIW, Firefox 57 is currently looking like a net loss in terms of security and privacy. A significant number of the extensions people have previously used for blocking or restricting potentially intrusive or dangerous behaviours seem to have been lost, in some cases without equivalent WebExtension alternatives being available.

If you're arguing that 57 is now more secure and better for privacy, perhaps you know something that people like me don't, and if so, maybe it's worth highlighting whatever built-in functionality can now replace those protections more in the documentation/marketing?


> FWIW, Firefox 57 is currently looking like a net loss in terms of security and privacy. A significant number of the extensions people have previously used for blocking or restricting potentially intrusive or dangerous behaviours seem to have been lost, in some cases without equivalent WebExtension alternatives being available.

First, I'd like to put things in context. When you write "Firefox 57 is currently looking like a net loss in terms of security and privacy", I suppose that this might (arguably) be true for you and a few other power users, but for the ~100% of users who do not use these power add-ons, their life will only be improved by the change.

Plus, I actually think that all the add-ons in the domain either have been ported or have an equivalent that has been ported. Certainly all the ones I use have been. Am I missing something that people actually use for their protection?

> If you're arguing that 57 is now more secure and better for privacy, perhaps you know something that people like me don't, and if so, maybe it's worth highlighting whatever built-in functionality can now replace those protections more in the documentation/marketing?

There is only so much message that marketing can propagate in a single campaign. I expect that we'll have another marketing campaign in a few months detailing what we've been doing for security and privacy. Especially since we'll have exciting stuff to showcase :)

Let me give you a few keywords of stuff we've been doing to improve security: a gazillion fixes, better static analysis, replacing some critical components with Rust, introducing the first formally proved implementation of cryptography components in a browser, sandbox improvements, etc.

On privacy, I'll admit haven't really paid attention, but the new add-ons you install don't have access to your private data without your consent, I remember that we've been working working with Tor Browser to reduce fingerprinting, etc.


I find it interesting that your instinctive view of privacy seems to be about restricting add-ons. That's certainly a useful thing to do, as we can see from some of the recent sell-outs that have meant once-trusted extensions silently became privacy loopholes. Even so, personally I'm more worried about the privacy implications of tracking and other covert behaviours by web sites/apps, and that's where the extensions you could run with Firefox really came into their own.

Someone has helpfully made a spreadsheet showing many old extensions and possible 57-compatible replacements, with notes on where things are a full replacement, there is limited functionality, there are known privacy issues, etc. I can't immediately find it again, so apologies for the lack of link, but have been references posted in some of the major online forums today, so perhaps you'll come across it. One of the things that was striking was that a lot of the extensions relating to blocking content or selectively toggling behaviours like running JS seem to have broken and not to have full replacements. I know that NoScript was a big one (though I've seen reports this evening that a 57-friendly version has just been released in that particular case). Quite a few ad-blockers and similar tools also seemed to have been affected, along with extensions like Greasemonkey that allow running customised JS and some analogous stylesheet customisers, and a few aimed at controlling the use of cookies and other data storage mechanisms.

For completeness, let me also say that the internal security improvements are all welcome, as is the continued separation of search from address bar and general lack of trying to spy on everything happening in the browser that seems to be ever-increasing in certain other quarters.


> Even so, personally I'm more worried about the privacy implications of tracking and other covert behaviours by web sites/apps, and that's where the extensions you could run with Firefox really came into their own.

This definitely makes sense. I know that we have new APIs that make some of it much easier to implement, but I imagine that they still have some limitations (I haven't checked). My hope is that APIs will be progressively extended to remove these limitations.

Regardless, I believe that we're better off with a sane API that add-on developers can trust, that we're going to maintain and extend, rather than with all-powerful stuff that breaks randomly :)


100%? Your arrogance is frankly infuriating.

Firegestures had 270k users, according to AMO. A quarter of a MILLION people.

You broke mouse gestures entirely on MacOS and Linux, and didn't allow them to work well on Windows (DOM needs to load before gestures can be used because you force script injection, don't work on internal pages, don't work on top of browser chrome, etc).


Playing the devil's advocate: the top two most popular extensions (as listed on [1]) are Adblock Plus at ~14 million, and uBlock Origin at ~4.2 million users. That means Firegestures has about 2% of the top extension, and about 1.5% if you combine the two (assuming not many people use both ad blockers at the same time, especially since they use the same lists). That's just the people with those extensions. And it appears that that's active daily users (as opposed to people have downloaded it at some point in a Firefox that is no longer being used).

I do agree that Mozilla has handled the transition terribly; they should have made the API available first before removing everything. That way they would at least have the excuse of it being the add-on authors not cooperating. The way they've done it, before actually making the things possible, just makes it look like they're arrogant.

[1]: https://addons.mozilla.org/en-US/firefox/search/?sort=users&...


Please read the thread before you chime in. We were talking about security add-ons. Mouse gestures are not security.

> ... but if it wants to keep users and remain significant, breaking arguably its main advantage might not be the best plan.

I fully expect that this move will certainly lose Mozilla a few Firefox users, but on balance it'll be a net win: they were already losing users to performance problems and lack of modern security features. The users the lose due to lost extensions will be tiny compared to the users they won't lose in the future now that Firefox actually feels like a modern browser performance- and security-wise.

I expect Mozilla knows a ton more about their users than we do and any guesses about user retention due to this move are pure speculation (including what I wrote above). I trust them to do the right thing here, a trust they've earned over the past (nearly) two decades that I do not place in, say, Google & Chrome.


> I fully expect that this move will certainly lose Mozilla a few Firefox users, but on balance it'll be a net win

I certainly hope so, for the sake of an open web. Hope they can take on the universal pushing and bundling that Google does with Chrome. Anecdotally I can say that none of my acquaintances are even aware of Firefox because Chrome can with their OS and they never saw a need to look beyond it. I hope Mozilla has a clear strategy to advocate and market Firefox, since technical merit alone is not going to out-compete Chrome's entrenched position.


Use 52ESR.

That's not true. Your browser does exactly the same things that it did yesterday.

If you chose to update to the new version where you knew exactly what extensions would be running and which wouldn't... well, your fault.


I didn't choose to update yet, for exactly that reason.

The problem remains that now I have to choose between:

56 (without security updates)

57 (without many useful extensions)

52ESR (without functionality and performance updates, and only until mid-2018 anyway)

Clearly none of these is as good as what I have had until this point.


You could try Pale Moon.

firefox autoupdates without prompting

i suppose that depends on your OS/update mechanism. mine doesn't.

EDIT: although i have it set to auto-update in the settings, maybe i just don't realize this because i never close/restart it heh :D


I think it's a little unreasonable to point blame at a group of people who largely built extensions on their own time, with no expectation of any form of compensation. It's entirely reasonable to decide you don't feel like supporting an extension anymore, and a community to take the reins doesn't just magically appear.

And regardless, there are still a lot of things that the old extensions API let you did that you simply cannot do with WebExtensions.

Having said that, Mozilla did the best they could in this transition. You can always argue that they cut over too soon, and that they should have waited until WebExtensions was a little more mature and covered more use cases, but the reality is you have to draw the line somewhere, and I'm sure they agonized for quite a long time over where that place would end up being. They also know a ton more about their users than any of us random HN commenters do and are way more qualified to make that decision than anyone here.


Two years without the APIs making a port possible.

Two years without saying which APIs they needed.

Simply false. You don't appear to know what you're talking about, so maybe you should stop pretending.

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


Anyone can read the bug report there and see what actually happened. Nobody even tried to detail what they needed until the VimFX came around a year ago to do so, and to begin workin on an experimental API. That experiment didn't really bear fruit until TWO MONTHS AGO, when the Firefox devs were knee-deep in the release cycle of their biggest product launch since version 1.0.

So yeah, the Firefox devs didn't have much to go on except inactionable "just do whatever Vimperator needs" junk, and no other vested interest seems to have lifted a finger to help the VimFX guy speed up his work on the experiment after he finally got the ball rolling, so blame doesn't really rest on the Firefox devs here.


That's not really the full picture.

One of the lead Firefox extension API devs is also the primary Pentadactyl (and former Vimperator) dev. I'm sure they were aware of exactly what was needed for that and similar extensions. They also made it clear from their earliest announcements that they intended supporting these extensions.

It simply isn't a priority which may be fair enough.

Pentadactyl still works well on ESR.


But the full picture also includes the fact that if all people were willing to do was wait for someone else to do the work, then they really have no high ground to complain that it didn't get done in the time-frame they wanted.

Other addon devs did help push things along, and they got the abilities they needed much sooner. We can only excuse ourselves so far before we share in the responsibility for things not getting done.


Totally agree with this. I think it was a mistake on Mozilla's part not to put more effort into extension parity before the switch-over. But I'm relatively optimistic for the future.

Have you seen the Firefox backlog? If they'd gone for 100% API parity before the switch, we'd have had to wait another three years for e10s, and I don't know if that would have been survivable.

I'm not happy about the situation as it stands, and I don't expect anyone else to be. I would be a lot more not happy about having to switch to Chrome because Firefox had become unusably slow - which it had already more or less done, before e10s started to land this year. Absent that I'd probably have had to switch already, just to be reliably able to get work done. And then there would be no one on the teams I've worked on who cared at all about maintaining Firefox compatibility, because everyone else already switched years ago. Less than ideal though the status quo be, I have a hard time seeing how any of that would be preferable.


> I have a hard time seeing how any of that would be preferable.

Not to you. But not everyone cares about the same things. I have used Firefox as my main browser ever since it split off from Mozilla Suite. Personally, I have never, in the whole history of Firefox had a problem with its speed. At various points I might have had some problems with stability, some problems with compatibility and some problems with memory usage. But speed is just not an issue for me. Even in the "slowest" browsers most of the time is spent on network latency anyway. But I have, over the years, customized my Firefox experience to some degree. I do not do anything crazy, I don't have a zillion of extensions, but I am really used to the few I do have. And this release broke those with no sufficient replacement. And the release was distributed as automatic upgrade, so I was not even asked if I want to upgrade. A warning of some sort would be nice before breaking so much functionality. And now that the upgrade happened, there is no clear way on how to revert it. A quick google search tells me that downgrading runs a chance of corrupting my profile. I might have to risk it anyway, since after using FF57 for a day at work, I feel that my productivity and workflow are seriously impaired. At this point I am not sure whether I should stay with the LTR version of FF, switch to an FF derivative like Waterfox or change browsers altogether. The FF57 experience is so vastly different from my pre-57 workflow that I might as well be using a different browser already. There were important features to FF that kept me a loyal user through many years. Those features are gone now.


I've been using Firefox for almost as long. Perf has been an issue for half a decade. Anecdotal evidence and telemetry analysis both suggest it's much more common to encounter the issue than not.

Don't get me wrong! I'd love to have both. But if we can't - and it seems right now that indeed we cannot - then I think perf has to be the one to pick. Otherwise the browser dies and we're all SOL.

Try backing up your profile and downgrading. I'd be surprised if anything breaks. Although I had also assumed anyone bringing legacy addons into 56 would be warned before the 57 update, so maybe I'm overly optimistic here.


> Personally, I have never, in the whole history of Firefox had a problem with its speed.

That's... weird. To put it nicely.

I've been using Mozilla since early in its milestone phases, and Firefox since it came out. Firefox was originally a pretty nimble browser, but fairly quickly became super slow. When Chrome came out I couldn't believe the difference in speed. Everything from UI responsiveness to rendering speed to reliability was better.

At some point I moved back to Firefox for a single reason: I had an 8GB laptop and Chrome's memory usage would balloon with the number of tabs I usually keep around, to the point that it made my laptop unusable. I lived with Firefox being much slower in general because its worst-case performance was much better than Chrome's on a memory-constrained laptop.

Since I force-enabled e10s a year or so ago things have gotten much better (despite the bugs). I still use Chrome every now and then for the odd website that chokes on some combination of Firefox plus the extensions I have installed, not to mention Chromecast support. But Firefox 57 is finally now faster than Chrome by default, and the difference is night and day. It's completely inconceivable to me that you suggest that Firefox hasn't had severe performance problems. The fact that Mozilla has been focusing so hard on perf for nearly a decade now is more than enough evidence to me that it's been a huge problem.


> That's... weird. To put it nicely.

I tried to explain it and I am not sure whether I am doing a bad job at it or people just don't believe me. I don't think browser speed matters. Even in the slowest days of Firefox, the time it took for content to download was longer or at least comparable to rendering time. Even now, with broadband access everywhere, if I look at dev tools, network access takes much longer than page rendering for most pages I access. So why should I care if rendering takes an extra second or two if it already takes just as long to actually get the content across the net. I do not expect web pages to be instantaneous, simply because they never are and so I do not get annoyed at render speed.

I do get annoyed when a forced upgrade removes features I relied on in my workflow.


> A warning of some sort would be nice before breaking so much functionality

There have been periodic warnings on HN's front page for two years.


No. A warning from the software itself. Something in the tube of "This is a major upgrade that drastically changes the browsing experience and breaks compatibility with addons you might rely on. Do you want to upgrade?". Instead, what I got was "Please restart Firefox to complete the upgrade".

Mozilla absolutely made the right decision to dump a decade's worth of legacy code to improve performance, and make the future happen now. Let's be real: had they supported legacy extensions, extension developers would ignore porting until Mozilla finally said "that's been long enough, we're removing legacy support". The result is simply that the rough transition happens now instead of a couple of years down the line.

Every popular extension will be ported within a matter of weeks, worst case scenario 2-3 months for those that are unabanonded, but less popular. If you are missing a deal-breaker extension, then don't upgrade yet... how is that a bad thing? "But I want the latest and greatest, super fast Firefox now - with all my extensions!". Talk about wanting to have one's cake and eat it too. The new Firefox wouldn't be new and improved if it was backwards-compatible with the stone age.


You forget the big technical issue: many web extension API features that are needed to port old Firefox extensions do not exist yet (e.g. filesystem access) or are conservatively crippled (e.g. adding buttons, menu items, other GUI elements). Your 2-3 months of frantic effort will start not immediately but in a vague future when the Firefox team feels like improving the web extension API. It is fairly obvious from API documentation and bug discussion threads that they only care for feature parity with Chrome web extensions, not with old Firefox extensions.

The transition could have been managed gradually, by piece by piece replacement of the old extension API with the new web extension API (made available to old style extensions). Extension developers would have made the small changes needed to port from a deprecated old API to a new API that does the same thing, up to the final step of reorganizing without significant code changes the old extension, now relying exclusively on web extension APIs, into a web extension. Abandoned extensions would have fallen by the wayside very fast, deficient APIs would have been fixed before actual usage, and Firefox would have moved forward without betraying users.


You're pretty much describing what Firefox has been doing for the past few years.

At some point, however, the rest of the world keeps moving and, no matter how painful for everyone involved, it becomes unfeasible to wait for all add-ons to be ported (or even portable).


What they're describing is hybrid WebExtensions, which were only introduced earlier this year.

not all, just mine

:)

"Betraying users"? 52 ESR isn't going anywhere, and I hope you'll forgive me for finding it a strain upon credulity to imagine that any regularly active HN participant could fail to observe even one of the many front-page articles over the past year which have talked about Firefox 57's breaking changes. If it means that much to you, stay on 52 for a year or two, until the extension API and ecosystem have had some time to catch up and stabilize. In the meantime, slinging heated rhetoric on the subject helps nothing and no one.

> 52 ESR isn't going anywhere

In 4-5 months, ESR will be replaced by Firefox 59, and support for 52 will end shortly after.

Sure, the old version isn't "going anywhere", but running an unsupported browser these days is pretty foolish security-wise.


It isn't a matter of "failing to observe": without the necessary API, extensions cannot be ported. I personally looked into rewriting the extensions I needed a couple of years ago, I figured out it was impossible and I gave up.

Some very important extensions have fortunately been able to pressure Firefox into supporting them, but the typical Firefox user who depends on some niche extensions has no clout.


Such is life. I'd rather have Firefox survive and continue to compete effectively than go chasing after perfect compatibility with those extensions I've also temporarily lost the ability to use until the necessary APIs land.

If Mozilla could have done both, Mozilla would have done both. They could not. I get that that's super frustrating. I'm not happy about it myself, because the change broke my workflow a little as well - until I engineered my way past that, because I'm a grown-ass adult and I solve my problems, or learn to cope, instead of whining about them - and also because I put myself on the hook for a Firemacs reimplementation that can't land for probably another year at best. That's annoying. I get it.

But slinging vitriol on the subject obtains nothing and aids nobody. It makes the people who do it look like jackasses, it makes the people who do the actual work feel like they can't win and may as well not try, and it makes everyone else embarrassed both on the behalf of the whiners and for their own sake in being associated, however loosely, with a community so full of Tumblr-grade drama. It's embarrassing and stupid and pointless and counterproductive and I wish people would stop. There are better ways to spend the same effort - like, for example, contributing patches to the webex implementation. Hard work, I know, and whining is easy. But that doesn't really play in favor of the whining, either.

(Yeah, I get that you're not really a major example of what I'm complaining about. You just happened to be right here when I lost my patience. All the same, though.)


They put 8 years of effort into extension parity. At some point you end up deciding that the breakage is less important than fixing foundational problems that cause people to leave your platform in droves due to the lack of ability to fix performance and security problems.

There are a few extensions I use that have stopped working that don't have a replacement (yet?), which sucks, but the tradeoff is well worth it.


Most of these were done by users scratching their itch. And I'm confident that's exactly why we'll get most of those experiences back.

Not necessarily. WebExtensions by design don't work on firefox pages, nor do they have full access to the browser like the old addons used to have. There are a few requests our there to get the needed access added, but Mozilla is basically going to let those rot: https://bugzilla.mozilla.org/show_bug.cgi?id=1215061


Sadly not how the FOSS world works any longer.

All that matters is the "shiny" (often wrapped in some kind of "social consciousness" claptrap), and those of us that has come to rely on existing behavior has to either suck it up, move on, or fork (And even forks struggle)...


I don't remember the FOSS world _ever_ working like you seem to think it should. The CADT Model[1] isn't exactly new and it wasn't really new when jwz coined the term either. Only the kernel, POSIX-y things, and enterprise software provides what you're asking for. And forks of Firefox struggle because writing a browser is really really hard and they can't keep up with the changes needed.

[1] https://www.jwz.org/doc/cadt.html


The one extension I'm missing (which has been broken since e10s) is cliget: https://github.com/zaidka/cliget

FYI: Firefox (and other browsers as well I think) already have built-in functionality for generating a cURL command with all the headers and cookies included.

In the dev tools, you can right-click on a request in the "network" tab and click Copy > Copy as cURL.

Sadly, this only works for requests you haven't already done with the dev tools open and it doesn't generate wget commands, but you might get some use out of this while the add-on is being updated.


This is my workaround for now, but Copy as cURL doesn't preserve the output filename given by the server. Not to mention it's a bit of a pain in the butt.

Adding -O usually takes care of that. I'm using curl with -L -O over wget now.

Are you missing having it in the context menu?


The download prompt mostly. Although the context option was sometimes useful it wasn't very reliable. Sites often don't give you direct links to download files that the context menu would help with.

That list is missing Hide Caption Titlebar Plus https://addons.mozilla.org/en-US/firefox/addon/hide-caption-...

I searched but failed to find a substitute for that....

That's a super-useful spreadsheet. Most of my extensions have at least alternate versions with some overlap on what I use.

This is also a pretty fantastic list of Firefox plugins in its own right. Thank you!

It needs an entry for RamBack[0]. Before installing RamBack, FF was very frustrating and I was seriously considering chrome

[0] https://addons.mozilla.org/en-US/firefox/addon/ramback/?src=...


Given the performance and memory usage improvements in FF57, it might not be necessary any more (I note that extension was last updated in 2007)

Hopefully it won't be necessary in FF57. Though I can attest that it is necessary in FF 54 and FF55

Tree Style Tabs has been updated to a WebExtension.[1]

Getting a menu bar no longer needs an extension, you can just right-click in the blank areas near the address bar and select "menu bar".

uMatrix can control and spoof Referer sending (I'm unfamiliar with RefControl, so this may not be exactly the same.)

Self Destroying Cookies[2] is a good way to keep cookies under control, though again I'm not familiar with the addon you mentioned.

[1] https://addons.mozilla.org/en-US/firefox/addon/tree-style-ta... [2] https://addons.mozilla.org/en-US/firefox/addon/self-destruct...


Self-Destructing Cookies is not a WebExtension, you want Cookie AutoDelete.

https://github.com/Cookie-AutoDelete/Cookie-AutoDelete/


Self Destroying Cookies is a WebExtension. There are now a couple of forks.

Hopefully one of them can deal with localstorage? Because my 30 mins of using cookie autodelete, leads me to think it isn't as good as self destructing... It doesn't seem to reliably delete cookies unless I click the "clean" button.


So, dumb question (maybe), but how do you get tree style tabs to install? I'm running FF 57 but that page says it's incompatible because I'm running FF 51. I checked and the user agent string being sent is:

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:51.0) Gecko/20170125 Firefox/51.0;


Stop spoofing your user agent string, install it, then resume spoofing. It should be

    Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0
by default for Firefox 57 on Windows 7 64-bit

I have never (to my knowledge) done anything to change the user agent. I dug around in about:config and discovered that general.useragent.override somehow got set.

Edit: Something is resetting that override every time the browser starts. Dunno what, the only addons I run are uBlock and RES (and now TST).

Edit 2: It was being set in user.js. No idea how it got there...


Do you have

  privacy.resistFingerprinting = true
set?

Nope, I discovered that it was being done in user.js. No clue how that happened...

I believe

  privacy.resistFingerprinting = true
spoofs user agent. Does anyone know if there is an addon or to whitelist which pages you don't want it spoofed on?

Click "See all versions" and scroll down until you find one that is compatible.

This new release is all about attracting new users to FF from Chrome. It will hurt those of us who actively have been using and living with Firefox.

In time, they say, they will bring back the various APIs for the extensions (although it's still "might" and there's no timeline yet) - so in the meantime, if you liked FF for it's customisation, we just have to suck it up. It's similar to when Ubuntu moved to Unity and attracted all the new users but pissed off all the existing userbase. We should expect a big backlash when all the linux repos get updated and the power users release they have a degraded experience.


Plenty of us have been using and living with Firefox without using one of the deprecated functions of XUL, or using them minimally. For those of us this release has been fantastic, and I'd wager we make up a considerably larger proportion of the userbase.

First off: Ich mag deinen Nutzernamen.

Second: I agree with your point that most of the userbase is most likely not running some weird addons that are hooked into the internals of FF via the old API. I actually suspect a rather significant portion of the userbase is running at most one of the handful of variants of ad- and/or scriptblocker.


It looks like some distros are going to take a bit of time to get Firefox >52 because of rust dependencies. They're definitely working on it, at least.

> This new release is all about attracting new users to FF from Chrome.

And I'm actually thinking of switching from Firefox to Chrome now.


Tree Style Tabs was the only blocker for me, and I was amazed that it was possible to recreate under the new API.

I use both Firefox and Chrome, but for very different purposes. In Chrome, I have 20-50 tabs spread across two windows. In Firefox, 400+. Tree Style Tabs is necessary for how I use Firefox. My backup plan was staying on an older version, possibly indefinitely.


The APIs are still being expanded. Tree-style tabs was near the top of the list of things they wanted to get support for before the deadline. They also had a bunch of bugs open for various features where devs could discuss use cases for potential APIs, and even "office hours" to work directly with extension devs to help them port their add-ons.

I was also very, very concerned about Tree Style Tabs. It's one of the main differentiators Firefox has for me over Chrome. Very happy it's mostly been preserved. I really only care about having my tabs on the side, not necessarily the nesting.

I personally find the nesting excellent because I am a junkie that opens 90 tabs at a time meandering through the internet and it gives a way to trace my context/history.

You're probably better off not updating yet. I'm unable to open my old session after the 57.0 update.

1283 tabs open in the session that I'm trying to open. FF56.0 the session opens in around 20 seconds. FF57.0 I let it try to open the session for 40 minutes and still wasn't finished.

Not sure how it would perform if it would manage to open all the tabs but currently it's pretty much unusable for tab-heavy user.

When starting a new profile and starting session from scratch the browser seems really nice. I'll try nightly at some point and see if it's any better. If not I guess I'll write some tickets for them.


Caveat: Of course your tabs should just open up in FF57.

But seriously, save all tabs as bookmarks. You're surely not using 97% of these tabs anyway.


400 tabs? 400?

I'm sorry if I sound a little condescending, but have you considered using bookmarks instead? I cannot even imagine a workflow where four flippin' hundred active tabs are needed.


It's not one workflow, and there is no scenario in which all 400 tabs are active at once.

Bookmarks take an extra step to save to, an extra step to load from, and do not stay in sync as I browse. Synchronizing a bookmarks folder with 10-20 tab changes would take significant human overhead.

Bookmarks are also slower to review than tabs, if you need to see anything besides the name/url/icon. You would need to load the bookmark into a tab before viewing it. Tabs are already in a tab, though not necessarily loaded.


You can be almost certain that people using hundreds of tabs have considered bookmarks and didn't find a better workflow using them, yes.

(Personally, I believe a good bookmark-like system could solve most reasons I have many tabs. But I neither know what exactly that'd look like nor do I want to spend the time developing it, so tabs it is)


Bookmarks have a really, really bad interface compared to tab trees.

Bookmarks are flat by default. You can make folders, but that takes manually opening the bookmarks manager and placing newly created bookmarks into the appropriate folder. Folders also waste space in the tree; one bookmark can't directly be the parent of another. The web doesn't have folders, it has links.

Bookmarks don't preserve structural context the way tab trees do. For example when using an API documentation site I'll open the site in a window, and from there open classes I need info on in tabs. Methods or related classes go in sub-tabs. I eventually end up with tabs for all the bits of the API I need to reference AND THE STRUCTURE!

Bookmarks are also hidden behind a menu, and are slow to access. Tabs can simply be suspended to save resources, and their trees collapsed.

Etc, etc. Bookmarks have horrible UX compared to tab trees.


Trees collapse, and typically represent recursive exploration of some particular area, and can act as a kind of task list or reading list. You collapse the tree when you're not actively drilling into that topic.

Combine with a solid session manager (I use Session Manager) to back them up regularly, and they fill in a third space between an open tab and a bookmark: something you only want to visit once, some time in the next few days / weeks, and have no desire to keep around longer than that.


I think 640 tabs should be enough for everybody ;)

I just learned this recently: https://en.wikipedia.org/wiki/Divine_fallacy

Maybe it is just me, but Tree Style Tabs is ridiculously slow on FF57. Takes about 3 seconds between the moment I hit F1 and the moment the TST sidebar is done loading.

The WebEx Tree Style Tabs is markedly inferior to the "Legacy" version. It is simply an integral and indispensable part of my workflow, so much that I can't even fathom browsing without it. I guess I'll stay on 56 for a while.

If you’re going to stay on a version then you’re probably better off on Firefox ESR as the current version will keep on getting security fixes until the middle of next year (by which time hopefully the features you’re missing will have come back).

I doubt it.

What is worse about it in your opinion? I was pleasantly surprised with how well it worked, and in fact the old extension had bugs for me where hiding the tab bar wouldn’t work properly.

No native context menus.

I'm of the other opinion. The legacy one was inferior, a couple bugs here and there, but usable. The new one removed the bugs I was having, and appears to be snappier. I just wish I could move the new tab button from the bottom to the top. Code doesn't look too hard, so I'll probably add a PR myself

Same for me, there’s no VimFX or Keysnail equivalent. I’ll just stay on firefox 57-0a1 (that’s an old alpha release, where (strangely) VimFX and the good old Tree Style Tab still work) for a long time.

What problems do you have with the new version?

- Open a new window: the tabs are not there by default - You need a css hack to hide the standard bar - There’s an ugly title thingy at the top of the tab pane

> Open a new window: the tabs are not there by default

It's not ideal but not a showstopper for me. I mostly use one window, where the toolbar is restored by default, and when I open a new window I got used to clicking the toolbar button (which I moved to the left) or pressing F1.

> You need a css hack to hide the standard bar

> There’s an ugly title thingy at the top of the tab pane

I just copied the "css hack" once and forgot. The last item is solved the same way. For those who don't know:

Inside the profile folder (with a name like "xxxxxxxx.default"), create a folder called "chrome", and a file inside called "userChrome.css" with the following content:

    #TabsToolbar, #sidebar-header {visibility: collapse !important;}
    #TabsToolbar {margin-bottom: -21px !important;}
IMHO It's quick enough to do and I believe this won't be needed in a few months.

Thanks! Here's how I did it on macOS:

1. Go to about:support in Firefox URL bar.

2. the address is in "Profile Folder" row.


Thanks! I didn't know that. It seems to be like that in other OSes too. I've tried to edit my previous comment but I was just over the time limit.

Brilliant! Thank you!

it's uber slow

What OS, CPU, etc? It's pretty fast to me.

MacOS Sierra, 3.1 Ghz Intel i7, 16GB of DDR3, SSD, ...

I have no idea why it's so slow.


It's uber slow for me too. Similar specs. Several hundred millisecond tab switches with a clean profile. Typing into slack is like typing into an SSH session over a bad dialup connection. Adding Tree Style Tabs kept my CPU over 20% and my fans running permanently. Maybe it's faster for people on Windows or Linux, but on macOS it's a major regression.

Sooooo did you make a donation to the author so that they actually have a reason to spend some of their personal time on improving it beyond the initial porting effort? I mean, they have a life they need to live and time they need to allocate too, right? If it's and indispensable add-on, you can probably part with a few bucks to help get it improved to the level you need, rather than the level the author felt was appropriate.

the author of TST is refusing donations AFAIK. He also said a lot of blockages came from Firefox and not from himself. I find it a bit sad that Firefox is not making TST a prime feature of Firefox. Are no Firefox developers using TST? I find that surprising.

It's possible most of them are now using the combination of tab containers and the "snooze tabs" extension, rather than trees. A test pilot feature that lets you mark tabs as "I don't want to see you until tonight/tomorrow morning/the weekend/next week/etc". It really cuts down on the need to keep 100+ tabs open (you just silo the tabs based on their role, then snooze all the ones you don't want to lose but don't need in the slightest right now either).

I've tried the snooze things for other things and I just ended up snoozing things again and again. Nowadays it's typical to have 10-20+ tabs open at all time that you're going to need during the day. That's already too much for tabs on top

> to get a menu bar back for Bookmarks

Is that something other than the "Bookmarks Toolbar" or the "Menu Bar" (which includes a bookmarks drop-down) that I can enable by right-clicking on the empty space in the toolbar?


I'm not sure what he's talking about either. I just upgraded and shockingly my menubar/bookmarks configuration was preserved. It looks a little tight but it's still arranged how I had it.

This might be too much for you, but if it's looking too tight, note that there's also a Density menu at the bottom in the customisation screen that lets you widen the interface (including, presumably, the bars).

I have my density set to compact, changing it affects the vertical space of everything except the bookmarks and menu bars. They remain incredibly tight.

That sounds like something that shouldn't happen! Care reporting it to them? https://bugzilla.mozilla.org/

I desperately wish FF showed the bookmarks bar on the new tab page like Chrome does. It makes bookmarks infinitely more usable for me.

Hopefully now there will be many developers with an itch they must scratch. Tree Style Tabs was the main blocker for me too.

That itch is perhaps better scratched over at Pale Moon, though i worry that even it is doomed...

To see tree style tabs updated so early is a so important to me.

I've even got the non-technical SO on tree style tabs, they consider the browser broken if the add-on isn't working.


I don't see how to disable yhe existing horizontal tab bar though? Now I have both that and tree style :/

You'll need a custom userChrome.css

    @namespace url("http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul");

    /* to hide the native tabs */
    #TabsToolbar {
        visibility: collapse;
    }
    
    /* to hide the sidebar header */
    #sidebar-header {
        visibility: collapse;
    }
You probably want to enable the menu bar if you do this, to stop the minimize/maximize/close buttons from overlapping the menu & other buttons on the right top corner.

>keymaster/gatekeeper/there.is.only.xul

Pretty amusing tbh


There is no OOB way to do it ATM, you need to modify the userChrome.css. see below for more details.

https://www.reddit.com/r/firefox/comments/736cji/how_to_hide...


I found it a good opportunity to reëvaluate which extensions I'm actually using. Most of them I wasn't.

For one reason or another, I reinstall an OS every couple of years or so, and start out with a fresh Firefox instance. I invariably end up with the same 14 or 15 extensions (delta is due to Linux work laptop vs Windows home PC). I use them all, but obviously my reliance on them follows the 80:20 rule.

I had them all synced for several years, surviving several data-losing crashes. I realized how I didn't actually use most of them.

Alright. Is anyone else here using Firefox's master password and found a solution in FF57?

I have been using Master Password+ extension for a very long time, but without it using a master password is hell. I had a lot of other modules, but this one was the reason I was still using firefox.

The annoying password prompt taking focus like popups in IE every time you open the navigator or a website you are not logged in is just crazy. It is annoying enough that I am asking myself if anyone at Mozilla even using Firefox accounts and master passwords.

Does anyone have a nice sync alternative to firefox accounts that include bookmarks and passwords (and it would be even better if I can sync using a git repo)


Sorry, I don't follow. I'm on Nightly (the 58-to-be) and I have Firefox configured to use a master password. It seems to come up once per session -- are you shutting down your browser constantly or something? I'm a little confused as to what specifically you don't like. (The one time it comes up is pretty jarring, I'll agree.)

I don't care about having to enter my password once at home. I care much more about having my navigator at work (which syncs all my personal accounts, including bank & government) being unlocked all day long, and much more when I'm not the only one to have admin access to my machine.

57 hasn't been released long enough for me to tell how it'll go... but when I dismiss the prompt once I don't want it to go modal every time firefox tries to sync or every time I click a link on a page I'm not logged in.


And thankfully Vimperator is getting ported to: https://addons.mozilla.org/en-US/firefox/addon/tridactyl-vim...

Very basic functionality already works.


Unfortunately, I don't think theres ever going to be a Classic Theme Restorer equivalent that works going forward.

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


A lot of that stuff is built into the browser, for people who care to look through the customization options and possibly do a tiny bit of about:config tweaking.

Have a look at https://github.com/Aris-t2/CustomCSSforFx , it can do many things, even if it's not a perfect Classic Theme Restorer replacement.

For me it's the Tab Groups add-on which is just irreplaceable! Firefox's "Containers" helps a bit but not that much.

Another Tab Groups user here.

Between Tab Groups and Tab Mix Plus for a multi-line tab bar I have to seriously redesign my workflow.

I could live with Tree Style Tab if it could nest tabs on the horizontal tab bar. I run FF on a portrait 1200x1920 screen and the vertical sidebar takes up too much space.


The TagGroups is so part of my daily basis that I went back to the v56.0

I cannot stress enough how it helps me to switch between contexts. It's one of those things that you just did not know that you needed so much.

What options do we have?


None that I know of. What helped me the most about Tab Groups was not just the tabs organization, but the face that I could create regular expressions so that a new page would automatically open in its own tab group (and everything else in one 'Default' tab group). That was a killer feature!

Take a look at Waterfox [0] fork (at the moment based on Firefox 55). Just successfully ported my ancient Firefox profile to it and all circa 20 legacy extensions are alive and kicking. Author seems to be willing to port features from Firefox trunk while preserving legacy features [1].

[0] https://www.waterfoxproject.org/ [1] https://www.reddit.com/r/waterfox/comments/79mwsc/waterfox_w...


> Hopefully most of the missing extensions will be developed sooner rather than later.

The API is still missing the ability to implement some things, which is preventing developers from supporting the latest Firefox.

I won't upgrade until Keysnail is able to run.


Moving to WebExtensions (a shared standard for extensions in Chrome/Firefox/Edge/Opera/etc) is good.

Much easier for extension developers (most extensions are unpaid open-source work) to support for multiple browsers.

To track the conversion progress for a particular extension, have a look here: https://arewewebextensionsyet.com/


I'm using Tile Tabs WE now instead of Tile Tabs, since that no longer works. Tile Tabs WE does it's tiling by opening new windows as a workaround, but I feel like that kind of misses the point.

Does anyone know of any alternative?

https://addons.mozilla.org/en-US/firefox/addon/tile-tabs-we/


According to the dev, a version that would work more or less like the original is waiting on https://bugzilla.mozilla.org/show_bug.cgi?id=1318532 which apparently has implementation but has been cockblocked for 3+ months by somebody in the review chain.

Ironically more Servo features could actually make this work better than the XUL version, such as supporting GL/CSS 3 transforms on the <webbrowser> components.

Take a look at Servo's current UI for how this could work.

Of course this doesn't help much with Quantum in its current state.


You don't need a plugin to get the menu bar back, you can just do (tap alt) View->Toolbars->Menu Bar, at least in FF56. I don't know for certain if that option still exists in FF57, but I hope it does.

I've been turning the menubar back on in Firefox for ages now. It's really dumb to hide it IMHO because they never used that space for anything else. It was just useless blank space.


Argh, it dropped one feature that I loved: clicking on current tab does a ctrl tab.

I'm using tree style tabs, but now I have both tabs in a sidebar (where I want it) and conventional tabs along the top. WTF?

If anyone can see how to disable the tab bar at the top, please enlighten me!



Tree Style Tabs is freaking slow since Firefox 57 unfortunately :/

It's worth noting that most legacy extensions still actually work. You just need to enable them.

You can't enable them in the release version of Firefox. You'd have to use Nightly, I believe.

That might be true for this release, but Firefox has committed to moving away from XUL. That means your extensions are guaranteed to break eventually.

They prevent you from using the modern features though.

There is a similar plugin(like Tree style tabs) for Chrome - Tabs Outliner

https://chrome.google.com/webstore/detail/tabs-outliner/eggk...

I was a Firefox zealot before they decided to go in this direction. For me Chrome does all the things FF does but much faster(at the moment).


Looks like it still uses a separate window, which is less than ideal, for me at least.

this plugin is bad. What is Chrome doing seriously :/ I've tried it a decade ago and it was still the same shit.
More

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact

Search: