<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<div class="moz-cite-prefix">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:<br>
<blockquote type="cite">
<meta http-equiv="content-type" content="text/html;
charset=windows-1252">
<p>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.</p>
</blockquote>
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".<br>
<br>
~ Gijs<br>
<br>
On 06/10/2016 16:08, Benjamin Smedberg wrote:<br>
</div>
<blockquote
cite="mid:CAK2U7KJTi2Er_xNxi-81Se_OWYDAALGEcSKACRUqs8hGAK2aJw@mail.gmail.com"
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 moz-do-not-send="true"
href="http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-webextensions/">http://benjamin.smedbergs.us/blog/2016-09-03/modularity-and-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="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
firefox-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:firefox-dev@mozilla.org">firefox-dev@mozilla.org</a>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/firefox-dev">https://mail.mozilla.org/listinfo/firefox-dev</a>
</pre>
</blockquote>
<p><br>
</p>
</body>
</html>