On Tue, Aug 30, 2016 at 11:44:35AM -0400, Benjamin Smedberg 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.
If we do this, we could as well reconsider the separation of browser and GRE files. Firefox is the only gecko-based application that does it. It was introduced for the metro UI, used by the webapp runtime, and was useful to ensure xulrunner toolkit files weren't trying to use Firefox files through resource://gre. None of metro, webapprt or xulrunner are a thing anymore. There's still a risk for toolkit using resource://gre urls for Firefox resources, though, and that can impact Thunderbird/Seamonkey/other third-party XUL apps. > 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. With all the stuff repeated between various nsBrowserApp.cpp-like files, with different level of support for the latest things in non-Firefox, this is more than welcome. That's something that I've been meaning to do for a long while, but this never reached a high enough priority to make it out of my TODO. > 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. If there aren't XPCOM binary components, I don't see what difference it would make if the XPCOM string API is exported or not. In fact, it could be removed, nothing should be using it through internal linkage. (And here, I really mean not-built, since it might be necessary to keep for comm-central) Mike _______________________________________________ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
