Followup: modularity, WebExtensions, and going faster

Gijs Kruitbosch gijskruitbosch at gmail.com
Thu Oct 6 15:40:50 UTC 2016


My understanding is that the webextensions API surface is fully async, 
in part to make it possible to eventually move them out-of-process. Some 
of the web, unfortunately, is still sync (hello, 
alert/onbeforeunload/inter-window direct JS calls, ...). Some bits of 
frontend are also expected to react in a synchronous manner. For 
example, it shouldn't be possible to end up with a situation where the 
user switches tabs and the location bar updates in a different tick of 
the event loop than the visualization of the selected tab (ie you'll see 
your google tab selected but the URL bar says mozilla.org). This fact 
makes me very skeptical of this paragraph:
>
> At the end of the day, I believe we should end up in a world where 
> most of the Firefox frontend is made available via system addons and 
> glued together using well-defined API surfaces. What would it be like 
> to have our tabbed browser, location bar, search interface, bookmarks 
> system, session restore, etc be independently hackable? It would be 
> awesome! It would mean a higher quality product, with more 
> opportunities for volunteer contributors to improve specific areas. It 
> would likely mean reduced edit/build/run/test cycles. It might even 
> give addon authors the ability to completely replace certain 
> components of the browser if they so choose.
>
It feels like at least some of the components you're referring to could 
not realistically be (a / separate) webextension(s) as a result of their 
needing to be "in sync".

~ Gijs

On 06/10/2016 16:08, Benjamin Smedberg 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.
>
> 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
>
>
> _______________________________________________
> firefox-dev mailing list
> firefox-dev at mozilla.org
> https://mail.mozilla.org/listinfo/firefox-dev


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.mozilla.org/pipermail/firefox-dev/attachments/20161006/c762d6d4/attachment.html>


More information about the firefox-dev mailing list