Have a look here [0] for legacy extensions replacements.
[0] https://docs.google.com/spreadsheets/d/1TFcEXMcKrwoIAECIVyBU...
[0] https://docs.google.com/spreadsheets/d/1TFcEXMcKrwoIAECIVyBU...
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.
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...
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.
Not to discourage asking for help, just that the source not being on github isn't super relevant.
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.
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.
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.
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.
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
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.
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'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.
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.
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.
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.
There have been periodic warnings on HN's front page for two years.
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.
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.
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).
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.
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.
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.)
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.
And the extensions' authors had, what, two years advance warning or so?
Criticize the real culpits, not Mozilla.
"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.
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.
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'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/
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?
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.
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.
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]
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...
"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 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.
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!
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.
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.)
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.
Pentadactyl still works well on ESR.
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.
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.
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 chose to update to the new version where you knew exactly what extensions would be running and which wouldn't... well, your fault.
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.
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
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.
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.
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?
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.
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.
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).
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&...
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 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.
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
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.
The point of your post on which I disagree is the idea that we need to name a "culprit".
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.
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.
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.
Years, in fact.
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.
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?
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.
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.
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.
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.
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.
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 :)
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.
[1] 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.
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.
(and sorry about your extensions)
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.
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.
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".
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.
[1]: https://github.com/torvalds/linux/blob/e7aa8c2eb11ba69b1b690...
Nor were they userspace: http://dblohm7.ca/blog/2017/11/16/legacy-firefox-extensions-...
It's the guideline from Linus and for a good reason. It's impossible to base work on shifting sands.
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.
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).
Have a good day.
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...
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
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.
Are you missing having it in the context menu?
[0] https://addons.mozilla.org/en-US/firefox/addon/ramback/?src=...