Followup: modularity, WebExtensions, and going faster

[Robert Helmer]

On Sun, Oct 9, 2016 at 9:57 PM, Benjamin Smedberg <benjamin at smedbergs.us> wrote:
>
>
> On Fri, Oct 7, 2016 at 6:12 PM, Robert Helmer <rhelmer at mozilla.com> wrote:
>>
>>
>> I agree. I think our problem is that hacking on Firefox is
>> exceptionally hard, and testing+shipping it is too. I don't think
>> either of things are hard because there aren't good enough boundaries
>> between different components.
>
>
> This is where I think we (Robert and I) fundamentally disagree. I believe
> that hacking on Firefox is exceptionally hard *because* there aren't good
> boundaries. I think there's a lot to discuss about the nature of those
> boundaries: JSMs versus WebExtensions versus future Rust versus HTML
> iframes. But we just don't have effective boundaries right now, and that is
> one of the reasons why hacking the Firefox frontend is so difficult and
> exhausting.

I do agree that we need to have boundaries, and that we want to do it
right. I'd be happy to be wrong that this will significantly move the
needle on making Firefox hacking more productive so I'll table that :)

I'm having a hard time conceptualizing how WebExtensions would fill
this role exactly.

Would Firefox then be a very basic "core" browser, implemented in
HTML/CSS/JS, with extensions for adding features on top of this
("awesomebar", bookmarks, devtools, etc?)  If so then the "core"
browser needs to implement WebExt APIs for each feature to use,
possibly with a "mozilla-only" permission if it's something we
wouldn't want third-party extensions to be able to do?

This feels like it would be an appropriate use of built-in extensions,
by adding features to the existing UI. If an extension fails for any
reason, then the feature is degraded but it continues functioning.
This also encourages us to make more good APIs available to the
third-party addon developer community, since we're dogfooding the APIs
ourselves (for the ones that are not "mozilla-only" which I imagine
there would be quite a few).

What about JS modules that multiple other features depend on, such as
the implementation of the WebExtension APIs themselves? We've so far
largely managed to avoid dealing with dependencies between extensions
(we made an exception for the new "WebExtensions Experiments" type of
addons, since the whole point there is to prototype new WebExt APIs
from an old-style extension).

I have more concerns about this - I think we want a simpler delivery
mechanism for core parts of the browser, and an extension that
implements some bit of functionality that is depended upon by other
features failing could be a lot harder to deal with.