Followup: modularity, WebExtensions, and going faster

[Robert Helmer]

On Thu, Oct 6, 2016 at 8:08 AM, Benjamin Smedberg <benjamin at smedbergs.us> wrote:
> I spent a week writing a thing about modularity, webextensions, and going
> faster. I think it's important for us to decide the module structure of our
> code especially as we start shipping independent modules/going faster. And I
> believe that having better module structure, boundaries, and documentation
> is critical to our teams being more agile and also attracting contributors
> to the project.
>
> http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/
>
> I personally think that we should double down on WebExtensions as a model
> and start using that for large parts of Firefox. But Andy McKay and Rob
> Helper had some good counter-thoughts and I've asked them to post here to
> elaborate.

I quite like WebExtensions as a replacement for Firefox extensions.
They are safer for users, easier to understand and control, enable
cross-browser extension development, and they reduce and better define
the extension API surface area we need to support.

We have explored using them for system addons (most likely as a
"hybrid" bootstrap.js + webextension), and there are some significant
drawbacks to using WebExtensions for browser features, which are
mostly due to intentional tradeoffs in the design of Chrome
extensions.

Gijs already pointed out that WebExtension APIs are all async (which
is on purpose), some other issues that come to mind:

1) WebExtensions currently don't (and Chrome likely never will) allow
modification of the UI beyond a few very limited things like adding
toolbar buttons, maybe things like menu entries in the not-too-distant future.

2) We would need to implement a *ton* of internal-only APIs that would
almost certainly never be implemented by any other browsers. Many
would likely only ever have a single caller.

I don't think there's any guarantee that our internal-only
WebExtension-style APIs would be any more stable, well-documented,
etc. than the code we currently consider internal-only. I suspect we'd
be tempted into implementing very general mechanisms that would remove
a lot of the safety arguments in favor of WebExtensions.

3) We're moving towards implementing more of the browser chrome in
HTML/CSS/JS, with some non-standard (and not appropriate to
standardize) APIs - a better approach might be to figure out
how to let Firefox update parts of the browser chrome in a similar way
to how regular web pages work.

For UI-specific features, it doesn't seem easier to use an extension
to modify the DOM or change the CSS, versus just modifying the HTML
and CSS directly.

For JS and binary components that UI features depend on, we could have
a simpler way to deliver just these and still not require restart.

If what we really want is to be able to ship updates to Firefox more
quickly and without requiring restart, and to be able to ship only the
new bits/bits that changed, it feels like there are more direct ways
we could do that safely using existing update mechanisms.

System add-ons are built on top of the extension mechanism because it
already exists and is relatively well understood, but I think we
should step back and re-think before we try to go down the road of
using this as the abstraction to build Firefox generally.

I'm not sure that more modularity is what Firefox needs to move
faster, especially given the lessons we can take from XPCOM from the
last decade or two.


> In the post I asked everyone to send followups to firefox-dev, so I wanted
> to start a thread here to collect responses. Over the next months I'd like
> this to turn into a firm decision about how we're going to build system
> addons; but I'd like to start by seeing what feedback people have and even
> whether I've framed the problem correctly.
>
> --BDS