On Tue, Aug 30, 2016 at 8: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. > To clarify, are you proposing a) removing all support for exporting XPCOM symbols from libxul full stop or b) changing the shipping configuration of Firefox to not export these symbols? _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
