Closed Bug 1214433 (webext) Opened 5 years ago Closed 4 years ago
[Tracking] Web Extensions Development
For the bugs that are targeted for 57 - use this query https://mzl.la/2oe1O9Z This bug is holding meta bugs related to webextensions. They aren't all ones that are committed to - but they give a way to see the meta bugs overview when talking about higher level capabilities.
Web Extensions are kind of there are already, but this tracks all the bugs we want to complete to get to a first release of Web Extensions.
Depends on: 1208257
Depends on: 1208761
Depends on: 1208775
Depends on: 1208874
Depends on: 1209184
Depends on: 1210583
Depends on: 1210996
Depends on: 1211366
Depends on: 1211665
Depends on: 1199718
Depends on: 1215775
OS: Unspecified → All
Hardware: Unspecified → All
Is this the death of FireFox? Let me rephrase it: will this make addons like "Classic Theme Restorer" impossible after XUL/XPCOM support is discontinued?
(In reply to Sergey Rozhenko from comment #1) > Is this the death of FireFox? Let me rephrase it: will this make addons like > "Classic Theme Restorer" impossible after XUL/XPCOM support is discontinued? Last I heard, the plan was to replace traditional XUL/XPCOM with a mechanism where a WebExtensions addon could depend on a more manually-reviewed "native.js" module which adds new APIs to what the WebExtensions environment can see. (The idea being that, over time, these "native.js" modules would get refined and then merged in as new official APIs.)
(In reply to Stephan Sokolow from comment #2) Ah, good then. I was worried we could lose the full customizability of FF, which is its core feature.
This was tracking stuff we wanted to do for 48. That version of Firefox has been and going. Sadly we didn't get everything on this list (there was a lot), but we got a lot of stuff done. We haven't really been using this tracking bug anymore, rather using the blocking-webextensions flag. For that reason, I'm going to close this bug.
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → FIXED
(In reply to Sergey Rozhenko from comment #3) > (In reply to Stephan Sokolow from comment #2) > > Ah, good then. I was worried we could lose the full customizability of FF, > which is its core feature. Indeed, that will happen, because the relevant bug was WONTFIXed on the grounds that native.js is incompatible with Mozilla's vision for Firefox.
(In reply to Mitth'raw'nuruodo from comment #5) > (In reply to Sergey Rozhenko from comment #3) > > (In reply to Stephan Sokolow from comment #2) > > > > Ah, good then. I was worried we could lose the full customizability of FF, > > which is its core feature. > > Indeed, that will happen, because the relevant bug was WONTFIXed on the > grounds that native.js is incompatible with Mozilla's vision for Firefox. *nod* Given that Firefox has no --enable-easy-off-store-extension-install equivalent to allow a secondary ecosystem to develop, as has occurred for YouTube downloaders on Chrome, that makes a XUL-less AMO even less free than Chrome's ecosystem. (Not even counting Firefox not yet having support for APIs like chrome.downloads.onDeterminingFilename) As soon as that change was announced, I started making plans to ride the trains down from Aurora through ESR and then switch to something like Seamonkey or Pale Moon. (Or even Chrome, given that Chrome at least has an actual menu behind the hamburger button rather than the "toolbar buttons in a panel" touchscreen/toy interface I'll be forced onto if Classic Theme Restorer dies out.) At the moment, given that I've finally lost faith in Mozilla and don't have high hopes for anyone else developing an acceptable ecosystem, I'm working to find/write browser-agnostic solutions for as much as possible of what I currently rely on extensions for (eg. adding a new root into the CA store and setting up an HTTPS-capable proxy to reinvent conveniences like InlineDisposition as well as my privacy and security extensions) in a way that'll work with any browser. ...and, of course, I've prioritized my efforts to write an external bookmark manager with an interface capable of scaling to the volume and complexity I need. (I already use an external password manager, so that's not an issue.)
...though I suppose another potential option would be if something like Qt's QWebEngine gained built-in support for loading WebExtensions. Then this push toward the lowest common denominator would mean it'd be feasible for me to maintain my own homegrown browser frontend on top of Blink+WebExtensions. (Actually, to be honest, that'd be even more appealing than if Firefox hadn't started retiring XUL.)
This bug was closed 10 months ago. Is it going to reopen for all these bugs that it depends on to be resolved?
Please stop adding dependencies to this bug.
You need to log in before you can comment on or make changes to this bug.