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.
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.
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.
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.
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
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.
"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.
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.
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.
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?
> 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 :)
> 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.
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.
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.
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!
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 :)
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.
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].
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.
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.
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'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.
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.
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.
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.
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.
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.
> "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.
> 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.
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.)
"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]
> 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.
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.
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!
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.
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.
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.
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 :)
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.
> ... 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.
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.
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.
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.
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.
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.
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).
"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.
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.
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
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.
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.
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.
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;
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...
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.
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.
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.
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.
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).
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.
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.
- 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:
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
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.
@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.
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.
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.
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.
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.
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].
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.
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.
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.