<div dir="ltr"><div class="gmail_extra">2016-10-12 8:26 GMT-07:00 Gijs Kruitbosch <span dir="ltr"><<a href="mailto:gijskruitbosch@gmail.com" target="_blank">gijskruitbosch@gmail.com</a>></span>:<span></span><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><blockquote type="cite">
<div dir="ltr">
<div class="gmail_extra">
<div class="gmail_quote">
<div dir="ltr">If you look, again, at session restore you
will have to go through all of them and it is far from
being obvious and will feel very hard to approach to
anyone except mozilla employees who have to learn all
these things. Web extension abstracts all that. The
difference between a content script and a background page
is very small. <br><span>
<ol>
<li>Is there a browser component that we can experiment
with, and attempt re-implementing with the
WebExtension API to see how it feels? Or, to take
rnewman's angle here, is there an opportunity here to
draw some new boundary lines and define a new (but
small) WebExtension Thing that combines capabilities
from several of our current modules for great good?<span class="m_-5573870297602042182m_-4095819469811120818gmail-HOEnZb"><font color="#888888"><br>
</font></span></li>
</ol>
</span></div>
<div>Session restore?<br>
<a href="http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/" target="_blank">http://blog.techno-barje.fr/po<wbr>st/2016/03/14/session-restore-<wbr>web-extension/</a><br>
</div>
<div>The big advantage to this particular feature is that it
doesn't involve much UI, which is where WebExtension is
the most limited.<br>
</div>
</div>
</div>
</div>
</blockquote>
... but then, is avoiding the UI problem really going to be helpful
in the future? How do we transition the experience from a
hypothetical successful session restore add-on to other frontend
features if we haven't solved that problem? And, most negatively,
how do we avoid that becoming boundary type number N + 1 (after
XPCOM, JSM, XBL, message managers, system add-ons, ...) that we then
don't get rid of and have to teach every contributor (employee or
volunteer)?<span class="m_-5573870297602042182HOEnZb"><font color="#888888"></font></span></div></blockquote><div><br><div style="font-size:small" class="gmail_default">The thing that doesn't seem to have yet been called out in this discussion is the difference between technologies that are local-only, versus ones that have broad documentation and support on the web at large (WebExtensions is arguably such a one).<br><br></div><div style="font-size:small;display:inline" class="gmail_default">It seems like some of the real wins going forward involve opportunistically aligning ourselves with existing larger stable development technologies/communities (presumably mostly from the web). (E.g. incrementally migrate from JSMs to CommonJS). Part of the trick here is to, over the longer term,<br></div><div style="font-size:small;display:inline" class="gmail_default">slowly let go of old proprietary technologies that are only known here, in favor of technologies known to large swaths of the web-development community, and broadly supported in common tooling.<br><br></div><div style="font-size:small;display:inline" class="gmail_default">An example of this is that most (many? all?) of the various Firefox sub-projects that use React have used mocha/chai/sinon for unit testing. Execution is at least an order of magnitude faster than any of the test frameworks commonly used in-tree, it's well-supported, constantly updated, has lots of interesting build tooling integrations in most IDEs and even in eslint, runs headless, etc. <br><br></div><div style="font-size:small;display:inline" class="gmail_default">Dan<br></div></div></div></div></div>