<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-10-12 16:45 GMT+02:00 Mike Conley <span dir="ltr"><<a href="mailto:mconley@mozilla.com" target="_blank">mconley@mozilla.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><ol><li>It might be worth considering re-implementing some browser components using WebExtensions. This would likely involve adding new, probably privileged APIs.<br></li></ol></div></blockquote><div>Yes. It would involve introducing new APIs, at least new features in the existing APIs.<br>For example for session restore, we would need to support a new parameter in addTab to allow loading tabs offloaded in the background (i.e. not load the url, but just display the tab and load it when you switch to it). I don't see any reason to not expose that to all addons.<br></div><div>But we would also need something to save and restore the various storage web api (localStorage, sessionStorage). This time it may be something we want to keep for internal addons?<br><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><p></p><ol><li>XPCOM / XPIDL, for better or worse, offered a boundary and interface system. I think those interfaces were originally intended to be pretty stable. Down the line, I seem to recall us deciding that having frozen interfaces there was slowing us down, and so now those interfaces are changed at will. I understand that we were more constrained because more applications were relying on the underlying interfaces, but this all starts to feel kinda familiar. Are we at risk of creating a new set of interfaces and silos that get holes poked through them over time because they slow us down instead of speeding us up? Are we repeating ourselves? If so, what did we learn last time that will make this time better?<br></li></ol></div></blockquote><div>We do have some boundaries with XPCOM, some others with JSM, yet some others with message managers.<br></div><div>But that's just too many different kind of boundaries/interfaces. If we only had one border, everything would have been much better.<br></div><div>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></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><ol><li></li><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="gmail-HOEnZb"><font color="#888888"><br></font></span></li></ol></div></blockquote><div>Session restore?<br><a href="http://blog.techno-barje.fr/post/2016/03/14/session-restore-web-extension/">http://blog.techno-barje.fr/post/2016/03/14/session-restore-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>