<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Oct 9, 2016 at 9:57 PM, Benjamin Smedberg <span dir="ltr"><<a href="mailto:benjamin@smedbergs.us" target="_blank">benjamin@smedbergs.us</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><span class="">On Fri, Oct 7, 2016 at 6:12 PM, Robert Helmer <span dir="ltr"><<a href="mailto:rhelmer@mozilla.com" target="_blank">rhelmer@mozilla.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span></span>I agree. I think our problem is that hacking on Firefox is<br>
exceptionally hard, and testing+shipping it is too. I don't think<br>
either of things are hard because there aren't good enough boundaries<br>
between different components.<br></blockquote><div><br></div></span><div>This is where I think we (Robert and I) fundamentally disagree. I believe that hacking on Firefox is exceptionally hard *because* there aren't good boundaries. I think there's a lot to discuss about the nature of those boundaries: JSMs versus WebExtensions versus future Rust versus HTML iframes. But we just don't have effective boundaries right now, and that is one of the reasons why hacking the Firefox frontend is so difficult and exhausting.<br></div></div></div></div></blockquote><div><br></div><div>As a relative newcomer to the Firefox world, I don't think that a lack of boundaries is the biggest hurdle one needs to overcome to hack on Firefox.  By and large, I've found that there are reasonable abstractions and usually at least some useful documentation.  Building blocks like IDL and JSMs provide a reasonable way to encapsulate some chunk of code, tools like dxr or searchfox make finding relevant interfaces/modules easy, and then between comments and MDN we have docs of variable quality.  Taken all together, there is room for improvement but its not bad.  Where I struggle is figuring out how these pieces fit together, especially in conjunction with larger things like e10s, compartments, etc. that transcend individual modules.  To give a concrete example, I was recently working on producing a notification for an event that begins with a script on a content page taking some action.  Finding PopupNotifications.jsm was easy enough and the docs were pretty clear that creating a notification required a <browser> element.  But figuring out how to get from some code running with a window reference in the content process to a place where I could create a notification took a lot of head scratching and more than a few false starts.  Once I figured it all out, I think that all the pieces of code involved are reasonably encapsulated and even have decent reference documentation.  But again, the big barrier was piecing together the big picture, not a lack of modularity in the actual components involved.  This is of course not an argument against modularity, just some observations about "why hacking Firefox is hard" from a newcomer's perspective.<br><br></div><div>As for WebExtensions, it is true that high-level APIs is an important goal for the project and to the extent we can use them widely, that promotes Benjamin's goal of modularity.  But the WebExtensions project also has other goals that I think conflict with the idea of using them extensively for browser internals.  The most obvious one is safety -- we've relied heavily on manual reviews for pre-webextensions extensions to ensure that when a user installs an extension that says it does one thing, they be confident that it isn't actually doing something else that they may not expect or want.  This process is more automated in webextensions in a few ways.  One is simply that that webextensions run with limited permissions by default and must explicitly declare further permissions that they need.  But another way is that in many places we've drawn a line around built-in parts of the browser and either forbidden or limited extensions from touching them.  As you might imagine, this has upset a lot of extension developers and there's been some lively discussion about this recently on dev-addons that I encourage you to read if you're interested.  But as it pertains to the idea of using WebExtensions internally, billm suggested earlier in this thread that the WebExtensions permissions system could be used here.  I think that's true in principle but extending the permissions system (and related to that, our processes for reviewing and signing extensions) in this way is not currently a goal for WebExtensions development, and it would take some non-zero amount of work to do.<br><br></div><div>My 2c etc...<br><br></div><div>-Andrew<br><br></div></div></div></div>