1214433 - (webext) [Tracking] Web Extensions Development

Status: RESOLVED FIXED

(WebExtensions :: Untriaged, defect, P4)

Description

[Andy McKay]

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.

Comment 1

[Sergey Rozhenko]

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?

Comment 2

[Stephan Sokolow]

(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.)

Comment 3

[Sergey Rozhenko]

(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.

Comment 4

[Andy McKay]

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.

Comment 5

[Mitth'raw'nuruodo]

(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.

Comment 6

[Stephan Sokolow]

(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.)

Comment 7

[Stephan Sokolow]

...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.)

Comment 8

[Matt]

This bug was closed 10 months ago. Is it going to reopen for all these bugs that it depends on to be resolved?

Comment 10

[Kris Maglione [:kmag]]

Please stop adding dependencies to this bug.