<div dir="ltr"><div>I'm all in for using more WebExtension. That's been a while I've been suggesting to do that:<br> <a href="http://techno-barje.fr/post/2016/03/14/session-restore-web-extension/" rel="noreferrer" target="_blank">http://techno-barje.fr/post/20<wbr>16/03/14/session-restore-web-<wbr>extension/</a><br> <a href="http://techno-barje.fr/post/2016/03/16/shipping-firefox-features-as-addon/" rel="noreferrer" target="_blank">http://techno-barje.fr/post/20<wbr>16/03/16/shipping-firefox-feat<wbr>ures-as-addon/</a><br>
<br>
Me and Vivien prototyped and demoed a browser to a few people at MozLondon.<br>
We ended up releasing that:<br>
<a href="http://techno-barje.fr/post/2016/06/28/html-experiments/" rel="noreferrer" target="_blank">http://techno-barje.fr/post/20<wbr>16/06/28/html-experiments/</a><br>
Which is not directly related to web extensions but is part of a bigger plan we have.<br>
<br>
We have another version, still to be released. A browser 100% made of WebExtensions.<br>
The current implementation splits the browser in 4 addons:<br>
* top level document addon, defining the various placeholders used
for the other addons. It defines the overall layout of the browser.<br>
* tabs, just display the tab strips and just that. i.e. document icon, title and the close button,<br>
* urlbar, just implement the url bar input,<br>
* "deck", implements the web views via a set of that display the web content.<br>
These addons are all web extensions and are using chrome.* APIs to implement the browser.<br>
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.<br>
<br>
This prototype is scary as it is yet another html browser written from scratch (tofino, browser.html, ...).<br>
But it exposes the opportunity to rewrite existing pieces of Firefox product and see them working in a brand, new, fresh product.<br>
The session restore addon I released on my blog works as-is in this html browser.<br><br>
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.<br></div><div><br>
We tried to get some traction at MozLondon but got none once we got back home.<br>
So all this work is just some side projects so far.<br><div class="gmail_extra"><br><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF"><div class="gmail-m_1018117537183829960m_-6536723415276962185moz-cite-prefix">
<br>
On 06/10/2016 16:08, Benjamin Smedberg wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">
<div>
<div>
<div>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.<br>
<br>
<a href="http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/" target="_blank">http://benjamin.smedbergs.us/b<wbr>log/2016-09-03/modularity-and-<wbr>webextensions/</a><br>
</div>
<div><br>
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. <br>
<br>
</div>
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.<br>
<br>
</div>
--BDS<br>
</div>
</div>
<br>
<fieldset class="gmail-m_1018117537183829960m_-6536723415276962185mimeAttachmentHeader"></fieldset>
<br>
<pre>______________________________<wbr>_________________
firefox-dev mailing list
<a class="gmail-m_1018117537183829960m_-6536723415276962185moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a>
<a class="gmail-m_1018117537183829960m_-6536723415276962185moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</div>
<br>______________________________<wbr>_________________<br>
firefox-dev mailing list<br>
<a href="mailto:firefox-dev@mozilla.org" target="_blank">firefox-dev@mozilla.org</a><br>
<a href="https://mail.mozilla.org/listinfo/firefox-dev" rel="noreferrer" target="_blank">https://mail.mozilla.org/listi<wbr>nfo/firefox-dev</a><br>
<br></blockquote></div><br></div></div></div>