<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Would Firefox then be a very basic "core" browser, implemented in<br>
HTML/CSS/JS, with extensions for adding features on top of this<br>
("awesomebar", bookmarks, devtools, etc?)  If so then the "core"<br>
browser needs to implement WebExt APIs for each feature to use,<br>
possibly with a "mozilla-only" permission if it's something we<br>
wouldn't want third-party extensions to be able to do?<br></blockquote><div><br></div><div>My big fear about this is that the choices we would make with those APIs essentially define the pillars of the application for years to come.</div><div><br></div><div>Good luck building anything novel on top of <font face="monospace, monospace">chrome.bookmarks</font>, which hard-codes the existence of "Bookmarks Bar" and "Other Bookmarks", is strictly hierarchical, can't be transactionally changed alongside a different data source, etc.</div><div><br></div><div>(Heck, good luck building the awesomebar on top of Chrome's bookmark and history APIs.)</div><div><br></div><div>And think we have trouble moving fast now? Try hard-coding and publishing an interface that you can't evolve without breaking all UIs built on top!</div><div><br></div><div>IMO it's a mistake to treat all interfaces as equal and public, which seems to be the point of the WE side of this discussion.</div></div></div></div>