<div dir="ltr"><div><div><div><div><div><div>As of this morning the important guts of this work have landed to mozilla-central and should ride the Firefox 53 trains. Here are the technical details, for those interested:<br><br></div><ul><li>The only XPCOM function intentionally exported from libxul is XRE_GetBootstrap. This function may be called once to get a class that allows firefox, xpcshell, plugin-container, etc to start.</li><li>The remaining guts of gecko are no longer exported: 
mozilla::Services, NS_InitXPCOM, NS_GetComponentManager and all the rest
 are internal-only.</li><li>There are a few helper functions for OS.File which are exported, which is not a problem in terms of blocking 3rd-party code.<br></li><li>The dependent XPCOM glue static library (xpcomglue_s) no longer exists.</li><li>The standalone XPCOM glue library (xpcomglue) still exists, with the sole purpose of loading libxul and calling XRE_GetBootstrap.<br></li></ul></div></div></div>I want to publicly thank Mike Hommey, Eric Rahm, and Nathan Froyd for helping with a bunch of tedious conversion/refactoring work to get this reviewed and landed!<br></div></div><div><div><div><br>I intend to file a bug for us to stop shipping and building the Mozilla SDK.<br><br><div>Mike
 and I are both working on some cleanup work after this: rearranging the
 files in xpcom/glue as well as making our startup code and sequence 
less crazy and spread across many files and directories.<br></div><div><br></div><div>--BDS<br></div></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 30, 2016 at 11:44 AM, 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>This is notice of an intent to change how we export symbols from the Firefox DLLs and binaries.<br><br>Currently our policy is that extensions may not include binary XPCOM components, and we've implemented some very basic rules that make it difficult for extensions to load these components. However, there is 3rd-party software that continues to use binary XPCOM: either by loading DLLs using ctypes and then using XPCOM, or injecting DLLs into the Firefox process.<br><br></div><div>Binary injection has been the cause of numerous crash issues in Firefox, which commonly show up as startup crashes when a Firefox update is first run. I believe that solving these crashes is a critical part of our Firefox quality story and our ability to release Firefox updates in a timely manner.<br><br></div><div>To that end, I believe that we should make it technically impossible for external DLLs to use XPCOM. I propose to do this in the following way:<br><br></div><div>Integrate the remaining Firefox binary component back into xul.dll using internal linkage.<br></div><div><br></div><div>Remove the XPCOM glue. This will involve reworking a little bit of how firefox.exe and plugin-container.exe initially load and launch gecko from xul.dll.<br></div><div><br></div><div>Remove most of the XPCOM-related xul.dll exports, and as many other exports as possible.<br></div><div>This includes all of the mozilla::services exports, as well as things like NS_GetComponentManager/NS_<wbr>GetComponentRegistrar, and a lot of the XRE_ functions like XRE_AddManifestLocation.<br></div><div><br></div><div>Undecided: whether we can or need to remove the "frozen XPCOM string API" exports. I'd like to, but it's not strictly necessary to solve the primary stability issues of external code using binary XPCOM, and I'm not sure what it would affect or how hard it will be.<br></div><div><br>I have prepared a list of current xul.dll exports from a recent nightly build, and proposed mitigations with bug numbers: <a href="https://docs.google.com/spreadsheets/d/1k2tFvEetMri2MT7viBM9iSVVt35dQH8O_mmNkYX9NOc/edit?usp=sharing" target="_blank">https://docs.google.com/<wbr>spreadsheets/d/<wbr>1k2tFvEetMri2MT7viBM9iSVVt35dQ<wbr>H8O_mmNkYX9NOc/edit?usp=<wbr>sharing</a><br><br></div><div>It is likely that this project will affect Thunderbird and/or SeaMonkey, but I'm not sure in what ways. My understanding is that Thunderbird currently builds with internal linkage. I plan to keep Thunderbird informed of the work here, and accepting patches that help Thunderbird stay building, but I do not intend to significantly delay or WONTFIX this Firefox work for Thunderbird.<br><br><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1299187" target="_blank">https://bugzilla.mozilla.org/<wbr>show_bug.cgi?id=1299187</a> is the tracking bug.<br><br></div><div>Please direct followup comments & questions to dev-platform.<br></div><div><br></div><div>--BDS<br></div></div>
</blockquote></div><br></div>