Followup: modularity, WebExtensions, and going faster

[Andrew Swan]

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

As a relative newcomer to the Firefox world, I don't think that a lack of
boundaries is the biggest hurdle one needs to overcome to hack on Firefox.
By and large, I've found that there are reasonable abstractions and usually
at least some useful documentation.  Building blocks like IDL and JSMs
provide a reasonable way to encapsulate some chunk of code, tools like dxr
or searchfox make finding relevant interfaces/modules easy, and then
between comments and MDN we have docs of variable quality.  Taken all
together, there is room for improvement but its not bad.  Where I struggle
is figuring out how these pieces fit together, especially in conjunction
with larger things like e10s, compartments, etc. that transcend individual
modules.  To give a concrete example, I was recently working on producing a
notification for an event that begins with a script on a content page
taking some action.  Finding PopupNotifications.jsm was easy enough and the
docs were pretty clear that creating a notification required a <browser>
element.  But figuring out how to get from some code running with a window
reference in the content process to a place where I could create a
notification took a lot of head scratching and more than a few false
starts.  Once I figured it all out, I think that all the pieces of code
involved are reasonably encapsulated and even have decent reference
documentation.  But again, the big barrier was piecing together the big
picture, not a lack of modularity in the actual components involved.  This
is of course not an argument against modularity, just some observations
about "why hacking Firefox is hard" from a newcomer's perspective.

As for WebExtensions, it is true that high-level APIs is an important goal
for the project and to the extent we can use them widely, that promotes
Benjamin's goal of modularity.  But the WebExtensions project also has
other goals that I think conflict with the idea of using them extensively
for browser internals.  The most obvious one is safety -- we've relied
heavily on manual reviews for pre-webextensions extensions to ensure that
when a user installs an extension that says it does one thing, they be
confident that it isn't actually doing something else that they may not
expect or want.  This process is more automated in webextensions in a few
ways.  One is simply that that webextensions run with limited permissions
by default and must explicitly declare further permissions that they need.
But another way is that in many places we've drawn a line around built-in
parts of the browser and either forbidden or limited extensions from
touching them.  As you might imagine, this has upset a lot of extension
developers and there's been some lively discussion about this recently on
dev-addons that I encourage you to read if you're interested.  But as it
pertains to the idea of using WebExtensions internally, billm suggested
earlier in this thread that the WebExtensions permissions system could be
used here.  I think that's true in principle but extending the permissions
system (and related to that, our processes for reviewing and signing
extensions) in this way is not currently a goal for WebExtensions
development, and it would take some non-zero amount of work to do.

My 2c etc...

-Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161010/1ee4fd8b/attachment.html>