The big problems are with really old extensions that used the antiquated XUL format. That's been on the way out for six or seven years, and it never worked on Firefox Mobile ("Fennec"). It's not like this was a surprise.
It's refreshing to have the perspective of somebody who actually had the problem.
Also, the stance of the ublock origin maintainer on this:
He clearly states why FF is NOT becoming a chrome clone as everyone says.
- In Webextensions, retrieving something from local storage is an async operation. In Jetpack, it was a sync operation. This has the potential to create race conditions if you're updating a cache. It's OK in my application, because a double update is harmless.
- Webextensions, by default, will run in incognito mode. That's because the "incognito" key in manifest.json doesn't support "not allowed" yet. (, table "Browser compatibility") That should have been both supported and the default, as it was in Jetpack, because it's a form of permission. Requires a one line workaround.
- The use of "id" requires a better explanation. When upgrading, you have to use the same ID your previous non-Webextension used, even though that ID ends with "jetpack". The documentation doesn't indicate anything like that. But the AMO uploader detects this and gives a good error message.
The new development and debugging environment on desktop is nice. The add-on worked the first time on Android, so I didn't have to use the more difficult environment for mobile debugging.
Tree Style Tabs itself will need to be redeveloped, but the necessary APIs are more or less available, and there are already similar add-ons that work in Firefox 57:
- Tree Tabs: https://addons.mozilla.org/en-US/firefox/addon/tree-tabs/
- Tab Center Redux: https://addons.mozilla.org/en-us/firefox/addon/tab-center-re...
The most significant missing feature is the ability to hide the native, horizontal tab strip. That's being tracked in https://bugzil.la/1332447.
At the beginning of this thread, the main dev states interest in migrating to WebExtensions, then cites all the bugs that prevent that. Towards the end of the thread, an extension dev (`nt1m`) states that the APIs have been approved, and simply need implementation in Firefox. There's definitely a chance they won't make it into 57, but the rapid-release cycle will help them land in a release not too long after 57.
If TST is essential to your workflow, you may wish to consider using 52 ESR until these APIs are finished in mainline, or contribute implementations of the APIs (time permitting, of course).
Although, I'm on ESR for now, mostly because my company admins cba to patch and enable java web start instead of java plugin for OEBS. Until recently it was stuck on java 1.6. They enabled recent java versions just a few month ago, so I guess I'm stuck with ESR for now.
The browser situation at the moment is pretty dire.
It looks like uBlock works with the new API, and there are Tree Style Tab replacements until TST gets the API changes it needs as well.
Speculation. I have only one extension I miss from the transition (lazarus), and I use tons of them. Most extensions of crap. Most important ones will be ported. I only see people going crazy over it in the tech saavy-complaining-experts crowd like HN comments.
> Firefox remaining userbase depends on these extensions.
I install Firefox on 20 to 30 machines every years. Most people just want ad block. Sometime last pass. The rest a rounding errors.
> With a marketshare below 3% sites will start ignoring it in favor of Chrome monoculture and subservience to Google.
3 %. LOL. You are one those dooms day persons right ?
I've never heard of Pentadactyl to this day.
So my guess you are a small user base, and Mozilla can safely accept to loose you.
You can't satisfy everybody.
What everybody want's right now is a faster browser. That's the main requested feature. That what's everyone agree on.
The new extension model is an important step to do that. There is no way around it. XUL extensions drag the browser down.
So if in order to satisfy most user FF has to let you down, it makes sense. It's sad. I understand your frustration. But it's the logical choice.
Talk for yourself, not on everyone's behalf
> I've been using Firefox for so long it was called phoenix at the time. I used a LOT of extensions, take part of the testing of unstable versions and test pilots and everything. I've never heard of Pentadactyl to this day.
Not a surprise. It's not like you have to memorize list of all extensions before using "unstable versions and test pilots and everything."
> So my guess you are a small user base, and Mozilla can safely accept to loose you.
Thanks for reminding us your use case is the only one that matters end everybody else is expendable.
You might have heard of Vimperator though, which Pentadactyl is a fork of. According to AMO, Vimperator has a lot more users and I guess the same implementation issues apply to it with regard to WebExtensions.
I switched over from Pentadactyl to Qutebrowser last year and it's way snappier. And with the experimental WebEngine backend, I haven't run into any rendering or performance issues at all. It also has a vertical tab mode, although it isn't possible to have sub-tabs like Tree Style Tabs.
I read this document: https://developer.mozilla.org/en-US/docs/Mozilla/QA/Bug_writ...
Does anybody have some suggestion on how to open a feature request for a webextension, it is better to first hop on an irc channel and ask there?
The full-stop disabling of legacy extensions will absolutely wreck my current workflow (Tab Groups, Vertical Tabs, Tile Tabs, etc.), to the point where I may need to explore alternatives. I don't like that thought, but I also don't see Mozilla giving power users like me much choice.
I'm kind of in the same boat as you. Vimperator is how is how I use my browser. Vimperator is pretty amazing in terms of functionality, but is also a good illustration why the WebEx migration is needed.
Vimperator can reload every tab every 10 seconds, create a temp buffer and open it in vim for textareas, control other extensions, modify headers or content of the HTML, control the chrome, and so on. From a developer or security standpoint having a plugin that can do this is insane.
That being said, I don't know what I'm going to do when the legacy stuff is fully deprecated. The plugins I use have become so involved in my workflow that I can't really picture Foxfire without them.
This way 99% of the users will never use unsafe addons, the 99% who won't even miss them. But power user who understand and want to, let them ultimately have the freedom to do "stupid" things (what you consider as stupid).
Whether Firefox add-ons should be restricted to what Google Chrome supports is another issue.
It's not, though. See: https://discourse.mozilla.org/t/support-ublock-origin/6746/4...
Many of the major performance improvements in Chrome were possible because the extensions were decoupled from the browser itself. If Firefox ever wants to improve its performance, it can not keep running XUL extensions anymore.
Where do you see the security implications, i.e. what is the threat model here?
0) Accept the loss, grieve, then move on to 57+.
1) Use ESR until 57+ becomes ESR someday.
2) Fork Firefox, rebasing your patch onto upstream.
3) Write a WebExtension, requesting APIs if necessary.
4) Stop updating Firefox, surf the web unsafely.
As a power user, each of these is within your theoretical capabilities. I cannot predict which is the appropriate tradeoff, though.
Also, the Tab Groups add-on you've linked still uses legacy APIs, and will not work as-is in Firefox 57, though we're actively trying to design an API that will allow it to work in 57 and beyond.
It's frustrating to see the only browser that cares throwing their user's concerns to the wind like that.
Though I kind of wish Mozilla had gone all the way to labeling them "for fucks sake stahp"
I'd love to be wrong on that though
> We will continue to honor this
preference in Nightly builds and in unbranded builds, but when 57 (and
later versions) go to beta and eventually to release, that preference will
Unless I'm mis-understanding that?
Additionally, aren't they are removing access to a lot of the internals even for legacy addons as well?
Nightly and unbranded builds will always respect that preference. Stable versions, starting with 57 will ignore it.
But when I go to https://addons.mozilla.org/en-US/firefox/addon/vimperator/, It wont let me install and it says "This add-on is not compatible with your version of Firefox"
Edit: Disabling JS allowed me to download it. It's not working yet, but I haven't had time to troubleshoot.
If you want to slow down the rate of UI / UX / product changes, consider trying Firefox ESR: https://www.mozilla.org/en-US/firefox/organizations/
Web developers stand the most to lose from people opting to run old browsers. Back in the IE6 days, it was justified, but by now, web APIs are already about as powerful as they're going to get, and we're reaching (or are long past) the point of decadence, churn, and bloat.
If you want to run old Firefox, take reasonable precautions, and you'll be fine.
Edit: down to -4. FWIW you can also securely run IE6 or literal malware.
We already have actors locking browsers down for (according to party line) the user's own good. Yet it seems Firefox is on the path to becoming Chrome, and not even extensions functionality will be a differentiation point. So what even is the "why" of Firefox?
Firefox is transitioning to an extensions model that is cross-browser and defined as a W3C draft. Their old extensions were Firefox-specific and could not be used by anyone else. This change seems very much in spirit with the open web.
When your extension does not or cannot work anymore due to lockout by browser consortium agreement, the control isn't with the user or the developer -- it's with the browser vendor. It kind of defeats the essence of extensions in the first place, which started out as a technique to give users and developers power over their user agents, and that's being reversed.
If what your user agent can do is dictated entirely by a consensus of a small number of browser vendors, the web becomes less open. Neither users nor developers wanted this.
That's a very broad statement to make, and I don't think you're in a position to say something like that.
For any extension that can be written with WebEx, this move is unambiguously a good thing. The developer can now just write their extension once and deploy it to multiple browsers. And for their users this is also a good thing, not just because reducing maintenance burden on the developer is more likely to lead to faster development, but also because AIUI WebEx has a much better permissions model than the old extensions.
The only real problem is the subset of extensions that cannot be rewritten with WebEx. Losing these extensions sucks, to be sure, but it's a tradeoff. You just can't claim that this move is strictly negative.
And given the last experiments in test pilots such as tab containers and snapshots, I can say they are still trying very hard to innovate. Personally, I LOVE the containers.
But just the fact they are creating rust to stay at the top of the line is proof enough they still got it.
Sorry, but that about sums it up, for me.
Firefox's extensions are a good part of what has kept the browser "the client", for me -- as in, software that works on the client's behalf as well as being the requesting functionality in the interaction.
I have no interest in moving to a client who is, more or less, working for the other end. Already had that in the past with Microsoft, and seem to be experiencing it again, more and more, with Google. No thanks.