WebExtensions API

[ghost]

https://blog.mozilla.org/addons/2015/08/21/the-future-of-developing-firefox-add-ons/

[lewisje]

Much like making uBlock for Microsoft Edge, this should mean easier cross-platform development going forward.

[LimboSlam]

Yeah and the death of many XUL, XPCOM and XBL add-ons. Hey...... What is Ublock built from?

[lewisje]

Even though there is an options.xul file in uBlock, I believe it's made with Jetpack, because it is restartless; also, I searched for the dreaded require('chrome') or require("chrome") and didn't even find so much as a require( in the codebase, and also the install.rdf file says the extension is bootstrapped and multi-process compatible.

TL;DR: uBlock will be fine in our brave new multi-process world.

[quilloss]

require('chrome') is not used because uBlock is not a SDK addon. The Firefox port currently uses the Components object to access XPCOM which is getting depreciated in around 18 months.

Hopefully the new WebExtensions API is fully compatible with Chrome's and uBlock would be just fine.

[gorhill]

I understand completely Mozilla's move. From a technical standpoint, maintaining and having to deal with huge amount of legacy code is a burden on resources, stability, performance and ability to easily improve performance or add features. There is a lot of silly overreaction going on (nowhere do they say they will limit FF to only a Chrome-like API).

Anyways, technical commentary. I see that FF41 will ship a webRequest-clone API. I have worries about its implementation though.

As far as I can see, the implementation of onBeforeRequest will cause the content process to be blocked until a network request has been evaluated^[1], while in uBlock the content process is minimally blocked, just the time to put key information in a circular buffer, that is all. In uBlock, the content process does not wait on the extension to decide whether a network request has to be blocked or not, this is all really done in the chrome process. Firefox's current implementation will cause the content process to be blocked until it has been completely decided whether network request must be blocked.

The way @Deathamns implemented this in uBlock resulted in minimally blocking the content process, and this shows when observing performance of uBlock (and uMatrix which shares much of the same Firefox-specific code) in e10s -- compared to other blockers out there.

After I took over the code I merely extended what was there to use a circular buffer mechanism to receives and store more information from the content process (to fix #211), which information is later retrieved in the HTTP observer (chrome process) when network requests have to be evaluated -- still minimally blocking the content process.

The duration for which the content process is blocked matters in e10s, as all tabs will share the same content process.

Maybe it's an idea they could pick from uBlock's code base, but then, they have better knowledge of all the Firefox's inner workings, there might be other reasons that I am unaware of to favor their chosen implementation.

---

[1] content process side, blocked until a response is received from chrome process side

[quilloss]

https://bugzilla.mozilla.org/show_bug.cgi?id=1163862
This bug seems to indicate that they plan to use HTTP observers instead of content policies for onBeforeRequest in the future.

[lewisje]

Will nsIContentPolicy be deprecated too?

[mattatobin]

Here is a question: What are the long term plans for Pale Moon support. When this is over it will be the only remaining browser that still uses those technologies Mozilla is removing.

[LimboSlam]

@mattatobin: possibly implement your own version of WebExtension API when it becomes stable and officially part of the Firefox code? Is that in our plans?? Is it even possible without using certain technology's we don't support, yet??

But of course finish the current projects we have going, that is our main duty.

[lewisje]

I've put in a request for Firefox to implement the declarativeWebRequest API, and if it does, that will be a definite advantage over Chrome, which has for years kept it at an experimental state, available in Beta and Developer editions but not Stable.

[mattatobin]

I doubt we will have WebExtensions API anytime soon if ever.

The Mozilla technologies are very powerful and has a rich repository of extensions that work perfectly fine without the need to constantly update them because we don't break everything every five minutes.

Stability of the extension framework technologies is something we take very seriously. It isn't treated fast and lose like at Mozilla. XUL, XPCOM, and other related technologies of our code base will not be abandoned for the sake of the new shiny.. It is a legacy we should honor and continue to evolve in a stable and rational way. It should not be sacrificed on a whim.

I guess developers will have to take that in account when/if they support Pale Moon.

[gorhill]

repository of extensions that work perfectly fine

There is no way to avoid making FF into a multiprocess-friendly application. To think that FF will stay forever a single process application is nonsense. Once you accept this conclusion, all the rest follows: the re-factoring is inevitable in order for FF to stay relevant long-term.

[mattatobin]

I am sorry to disagree but multi-process was not a requirement nor a necessity.. A well balanced multi-threaded application could do just as well with far less resources. The idea is to not make your application more tolerant of faults but to try and eliminate the faults them selves.

[wolfbeast]

Multi-process doesn't even have anything to do with what extension framework you choose to use.
Also, multi-process is not a requirement in any way shape or form for using multiple processors (despite the similarity in name). So, please keep this argument out of this because it's completely irrelevant to browser extensibility.

[gorhill]

@wolfbeast pay attention to what I quoted:

repository of extensions that work perfectly fine

No, the repository of extensions does not work "perfectly fine" with e10s.

[mattatobin]

Pale Moon does not ship with e10s.

What I would like to know is if ublock will continue to support Pale Moon as an independent target despite what Firefox does.

[gorhill]

Will uBlock Origin continue to support Chromium as an independent target despite what Chromium does?

I don't know.

Will uBlock Origin continue to support Opera as an independent target despite what Opera does?

I don't know.

Will uBlock Origin continue to support Firefox as an independent target despite what Firefox does?

I don't know.

Will uBlock Origin continue to support Pale Moon as an independent target despite what Pale Moon does?

I don't know.

Will you continue to maintain uBlock Origin forever?

I don't know.

Bottom-line: I don't know what will happen in the future, so I don't commit to anything.

[temsa]

@gorhill : implementing the extension using WebExtensions API would provide an easy to use support for system-wide content blocking for FirefoxOS, quite a game changer IMO :)

Plus, most FirefoxOS phones have a "small" hardware, so it would probably boost the phone performances as well while navigating

[gorhill]

implementing the extension using WebExtensions API would provide

It's already done, that is what the Chromium version is.

[temsa]

Yes... And no : I'll personally consider it as done when I'll see it
available on the firefox marketplace so I can install it on my phone ;)

On Tue, Nov 10, 2015, 19:17 Raymond Hill notifications@github.com wrote:

implementing the extension using WebExtensions API would provide

It's already done, that is what the Chromium version is.

—
Reply to this email directly or view it on GitHub
#622 (comment).

[Daktyl198]

@gorhill While I believe the Chromium version should run fine on the initial WebExtensions release (currently set to FF48), you do have to add at least one thing to the manifest.json file specific to Firefox:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/manifest.json/applications

After that, testing it is simple:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Porting_from_Google_Chrome

And then you can upload the "WebExtensions" version to AMO right away (they're currently accepting them for review).

[coladict]

The new API is coming and the old one is being killed. Perhaps it's time this issue becomes a priority.

I believe that the cause of #1973 is most likely that @uptonn is of the 1% of users that Mozilla is testing their multi-process version from on using Firefox 48 public release.

[gorhill]

uBO works fine on Nightly -- most likely explanation is that the SQL database was corrupted and this broke uBO's internals. These cases of corrupted SQL database crop up once in a while (it's out of uBO's control, it merely uses the FF API to access the SQL database).

[gorhill]

Started to work on this, related Bugzilla entry: https://bugzilla.mozilla.org/show_bug.cgi?id=1309926.

Currently blocked because of an incomplete API:

uBO's Port.onMessage's listener is not being given the port argument when being called.

Need to open a Bugzilla entry for this.

[gorhill]

Will first need to convert the current webext-only version of uBO into a hybrid version, to seamlessly transition storage data from legacy to webext, as per https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Embedded_WebExtensions#Migrating_data_from_legacy_add-ons.

[Darkspirit]

@gorhill

Will first need to convert the current webext-only version of uBO into a hybrid version, to seamlessly transition storage data from legacy to webext

But please keep the current webext[-only].xpi version and make the firefox.xpi to a hybrid version. Maybe you had that in mind. Thank you <3

[AlexBeLi]

I'm sorry for offtop but what about this? Rules like foo.example##script:contains(nuisanceCode) will be worked in webext or not?

[gorhill]

Rules like foo.example##script:contains(nuisanceCode) will be worked in webext or not?

No.

[RichardJECooke]

Hi, I'm confused, I see this 4 year old issue is closed, but uBlock just stopped working in my Firefox 57. How do I fix it please?

[Hrxn]

@RichardJECooke

Are you sure it's not that Firefox bug? Like, their fuckup that broke basically all extensions? (Do other extensions work on your side?)

https://blog.mozilla.org/addons/2019/05/04/update-regarding-add-ons-in-firefox/