Hooray! This change prevents a significant cause of crashes. Nick
On Fri, Jan 20, 2017 at 2:47 AM, Benjamin Smedberg <benja...@smedbergs.us> wrote: > 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/1k2tFvEetMri2MT7viBM9 >> iSVVt35dQH8O_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 >> > > > _______________________________________________ > firefox-dev mailing list > firefox-...@mozilla.org > https://mail.mozilla.org/listinfo/firefox-dev > > _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
