Followup: modularity, WebExtensions, and going faster

[Alexandre poirot]

I'm all in for using more WebExtension. That's been a while I've been
suggesting to do that:
  http://techno-barje.fr/post/2016/03/14/session-restore-web-extension/
  http://techno-barje.fr/post/2016/03/16/shipping-firefox-features-as-addon/

Me and Vivien prototyped and demoed a browser to a few people at MozLondon.
We ended up releasing that:
  http://techno-barje.fr/post/2016/06/28/html-experiments/
Which is not directly related to web extensions but is part of a bigger
plan we have.

We have another version, still to be released. A browser 100% made of
WebExtensions.
The current implementation splits the browser in 4 addons:
 * top level document addon, defining the various placeholders used for the
other addons. It defines the overall layout of the browser.
   * tabs, just display the tab strips and just that. i.e. document icon,
title and the close button,
   * urlbar, just implement the url bar input,
   * "deck", implements the web views via a set of  that display the web
content.
These addons are all web extensions and are using chrome.* APIs to
implement the browser.
For example urlbar uses chrome.tabs to listen for location change and load
another URL. Actually all these addons are heavily based on tabs API.

This prototype is scary as it is yet another html browser written from
scratch (tofino, browser.html, ...).
But it exposes the opportunity to rewrite existing pieces of Firefox
product and see them working in a brand, new, fresh product.
The session restore addon I released on my blog works as-is in this html
browser.

Using WebExtension is a way to move forward and really untie us, not only
from XUL, but also from the tall beast Firefox frontend code became. All
test pilot addons are meant to be bound to gecko and Firefox frontend.
There is no easy way to get them to work easily on Tofino, browser.html or
any new thing we would like to come up with. Having such ecosystem with
core firefox features implemented as addons would allow having test pilot
experiments drastically changing the browser experience and not stick to
just hacking (hardly) in browser.xul.

We tried to get some traction at MozLondon but got none once we got back
home.
So all this work is just some side projects so far.



> 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 listfirefox-dev at mozilla.orghttps://mail.mozilla.org/listinfo/firefox-dev
>
>
>
> _______________________________________________
> 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/b3118892/attachment.html>