Intent to ship: webextentions startup changes (plus an important note for authors of webextension experiments)

Andrew Swan aswan at mozilla.com
Fri Apr 6 02:24:10 UTC 2018


(bcc firefox-dev, please follow up to dev-addons)

tl;dr: Some changes are coming that should both improve browser startup
times and make extensions that affect resource loads (e.g., ad blockers and
other privacy-related extensions) more reliable during browser startup.
These changes will initially be behind a preference and limited to nightly
but we hope to have them ride the 62 train for general use.

Background: Many popular WebExtensions use the webRequest API [1] to block
undesired network requests.  Using this API involves calling a function
(e.g., browser.webRequest.onBeforeRequest.addListener) to register a
blocking handler for some requests.  This is typically done from an
extension's background page [2].  We currently start loading extension
background pages relatively early during browser startup but this has a few
problems.  First, many extensions do work in their background pages that
really doesn't need to happen during startup.  Having them start early
undermines all the work that has happened recently to improve browser
startup times.  On the other hand, loading a background page is an
asynchronous process so it is possible for some content loads to take place
before extensions that might block some loads get an opportunity to
register their blocking webRequest listeners.

The solution: In bugs 1450388 [3] and 1447551 [4] we will extend the
framework used for handling WebExtension events to allow some events to be
"persistent".  When an extension creates a listener for one of these
events, we will record that fact in the profile.  On subsequent browser
startups, we will install the event listener as early as we can during
startup but also defer starting the background page until after other
important browser startup work is done.  When one of these events happens
before the background page is started, the stub listener will still suspend
network requests as necessary until the background page has started and the
extension-provided callback is available.  Although we're starting with
webRequest, we intend to extend this handling to other APIs such as proxy
that can affect content loads during startup.

Deferring the startup of background pages may have other consequences so
this will be behind the preference webextensions.background-delayed-startup
though that will default to true on Nightly when bug 1447551 lands.  Please
let us know (by filing bugs or coming to #webextensions on IRC) if you see
any problems that might be related to this change.

Finally, if you maintain a WebExtension experiment that implements events,
the signature for constructing an instance of EventManager is changing in
bug 1450388.  We've put a shim in place to avoid immediate breakage but
you'll need to update your experiment so it doesn't break when the shim is
eventually removed.

This email is relatively light on details, if you're interested in learning
more or have questions, feel free to comment on one of the bugs or come ask
on IRC.

-Andrew


[1]:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/API/webRequest
[2]:
https://developer.mozilla.org/en-US/Add-ons/WebExtensions/Anatomy_of_a_WebExtension#Background_scripts
[3]: https://bugzilla.mozilla.org/show_bug.cgi?id=1450388
[4]: https://bugzilla.mozilla.org/show_bug.cgi?id=1447551
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20180405/c709a76c/attachment.html>


More information about the firefox-dev mailing list