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:
- 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. - The remaining guts of gecko are no longer exported: mozilla::Services, NS_InitXPCOM, NS_GetComponentManager and all the rest are internal-only. - There are a few helper functions for OS.File which are exported, which is not a problem in terms of blocking 3rd-party code. - The dependent XPCOM glue static library (xpcomglue_s) no longer exists. - The standalone XPCOM glue library (xpcomglue) still exists, with the sole purpose of loading libxul and calling XRE_GetBootstrap. 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! I intend to file a bug for us to stop shipping and building the Mozilla SDK. 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. --BDS On Tue, Aug 30, 2016 at 11:44 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > This is notice of an intent to change how we export symbols from the > Firefox DLLs and binaries. > > 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. > > 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. > > 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: > > Integrate the remaining Firefox binary component back into xul.dll using > internal linkage. > > 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. > > Remove most of the XPCOM-related xul.dll exports, and as many other > exports as possible. > This includes all of the mozilla::services exports, as well as things like > NS_GetComponentManager/NS_GetComponentRegistrar, and a lot of the XRE_ > functions like XRE_AddManifestLocation. > > 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. > > I have prepared a list of current xul.dll exports from a recent nightly > build, and proposed mitigations with bug numbers: https://docs.google.com/ > spreadsheets/d/1k2tFvEetMri2MT7viBM9iSVVt35dQH8O_mmNkYX9NOc/edit?usp= > sharing > > 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. > > https://bugzilla.mozilla.org/show_bug.cgi?id=1299187 is the tracking bug. > > Please direct followup comments & questions to dev-platform. > > --BDS > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
