Before bug 938437, we had a rather large and error-prone
nsStaticXULComponents.cpp used to register all modules. That was
replaced with clever use of the linker, which allowed to avoid the mess
that maintaining that file was.
Fast forward to now, where after bug 1524687 and other work that
preceded it, we have a much smaller number of remaining static xpcom
components, registered via this linker hack, and don't expect to add
any new ones. The list should eventually go down to zero.
Within that context, it seems to be the right time to get rid of the
magic, and with it the problems it causes on its own.
Some of those components could probably be trivially be converted to
static registration via .conf files, but I didn't want to deal with the
possible need to increase the number of dummy modules in XPCOMInit.cpp.
They can still be converted as a followup.
Differential Revision: https://phabricator.services.mozilla.com/D26076
--HG--
extra : moz-landing-system : lando
The binary path type of a particular content process is useful information
outside of IPC. Given that `XRE_EnableSameExecutableForContentProc` already
exists, and given that the binary path type is closely related to
`GeckoProcessType`, I've added a new function, `XRE_GetContentProcBinPathType`.
The mapping of process type to binary type has been moved to the
`GeckoProcessTypes` definitions.
This patch also modifies `ipc::GeckoChildProcessHost` to call into the new
function.
Differential Revision: https://phabricator.services.mozilla.com/D25816
--HG--
extra : moz-landing-system : lando
Produces a help text that conforms to the line width recommendations
of nsICommandLine.
On the other hand, the formatting of the source code itself is
rendered rather ugly by clang-format.
Differential Revision: https://phabricator.services.mozilla.com/D26583
--HG--
extra : moz-landing-system : lando
Add an RAII guarded initialization for the IO interposer to the
initialization process for content processes. This ensures that whenever
a content process uses the IOInterposer, that it will correctly catch
all registered threads, and will not miss any.
Differential Revision: https://phabricator.services.mozilla.com/D20737
--HG--
extra : moz-landing-system : lando
Move sandbox early start logic to GeckoChildProcessHost.
Move sandbox CLI param logic into MacSandboxInfo.
Differential Revision: https://phabricator.services.mozilla.com/D22409
--HG--
extra : moz-landing-system : lando
The definitions can't be entirely removed yet because NSS still needs them.
Differential Revision: https://phabricator.services.mozilla.com/D23454
--HG--
extra : moz-landing-system : lando
When Android shuts down the ndk process, it doesn't call the registered
atexit() handlers, which is normally where the profile data gets written
to file. Since the PGO test suite closes the browser when it is
finished, the nativeRun routine can manually call out to
__llvm_profile_dump() before returning.
This method has a downside that only the profile data from the calling
library gets written out, rather than for the whole process. Since we
are most interested in optimizing libxul, a new hook is added in
Bootstrap to make sure we get the profile data for the right library.
Differential Revision: https://phabricator.services.mozilla.com/D22817
--HG--
extra : source : 0615c775a0cf6e8f98e1c051cd574c0d602a738a
When Android shuts down the ndk process, it doesn't call the registered
atexit() handlers, which is normally where the profile data gets written
to file. Since the PGO test suite closes the browser when it is
finished, the nativeRun routine can manually call out to
__llvm_profile_dump() before returning.
This method has a downside that only the profile data from the calling
library gets written out, rather than for the whole process. Since we
are most interested in optimizing libxul, a new hook is added in
Bootstrap to make sure we get the profile data for the right library.
Differential Revision: https://phabricator.services.mozilla.com/D22817
--HG--
extra : moz-landing-system : lando
If configured to show the profile manager on startup we want to defer doing that
until after attempting to remote to an existing Firefox. So in the default
startup case (not first run, not when a profile is selected on the command line
and not when the profile manager is requested on the command line) let default
profile selection complete, check for an existing Firefox and only then check
that we're configure to show the profile manager on startup and show it then.
Differential Revision: https://phabricator.services.mozilla.com/D23410
--HG--
extra : moz-landing-system : lando
* We remove the launcher process prefs from `firefox.js` and just use defaults
at the time we access the pref;
* We set the pref to true by default on nightly and beta;
* We modify `SetupLauncherProcessPref` to save the initial state of the
launcher process to `gLauncherProcessState` to reflect the status of the
launcher process *at startup*;
* We modify `nxXULAppInfo::GetLauncherProcessState` to call
`SetupLauncherProcessPref` as the former may be called from JS ahead of the
call to `SetupLauncherProcessPref` that we do in `XRE_mainRun`;
* We modify `LauncherRegistryInfo::ReflectPrefToRegistry` to not clobber any
registry settings unless the new pref value differs from the previous pref
value. We also update the test to reflect this change.
Differential Revision: https://phabricator.services.mozilla.com/D21789
--HG--
extra : moz-landing-system : lando
The main changes here are to stop checking if we're shutting down when we
already know we are shutting down and making sure the windows remote server
shuts down properly.
I also spotted that nsINativeAppSupport.quit is now unused so I removed it.
Differential Revision: https://phabricator.services.mozilla.com/D22771
--HG--
extra : moz-landing-system : lando
If the user selects a profile we will either remote the current arguments to it
or we'll restart into it. Either way we don't need to check if the profile is
locked at this point.
We also don't need to double check if the profile is missing since bug 1530615
landed.
Differential Revision: https://phabricator.services.mozilla.com/D22758
--HG--
extra : moz-landing-system : lando
Implements the windows remove client and server based on the current remoting
code in nsNativeAppSupportWin.cpp. Makes the hidden window classname encode both
program name and profile name. nsNativeAppSupportWin is now just used for
setting up the console.
Differential Revision: https://phabricator.services.mozilla.com/D19076
--HG--
extra : source : 84e8066625fd72fdb1eb6eab85621ae842fe91b4
extra : amend_source : b698f986cce0ccfae29c04fcbe0d84a6c8605ab6
Adds build config and stubs for a windows implementation of the remote client
and server.
Differential Revision: https://phabricator.services.mozilla.com/D19074
--HG--
extra : source : abd7789e9637c92978efcf745361b98c5abf847a
extra : intermediate-source : 276ca640adc8ff16ff3ff7252e8aa5016205b1e0
Makes it so we always know which profile we want to remote the command line to.
Differential Revision: https://phabricator.services.mozilla.com/D19073
--HG--
extra : source : f1f569797e33b390ba588351e826fa979b018f01
extra : intermediate-source : 967993505a3d00a79cd81dccf66ffa0612a58ad4
Makes nsRemoteService handle the command line parsing, though this will end up
being removed in a later patch.
Differential Revision: https://phabricator.services.mozilla.com/D19071
--HG--
extra : source : 5c648e7641a72770d89a5408ac01de3b5de15c6b
extra : intermediate-source : fc466857ab39e3d2371f13ddae553c921fb727d2
Makes nsRemoteService responsible for the shared lock for the time between
attempting to contact a remote server and starting up our own server.
Differential Revision: https://phabricator.services.mozilla.com/D19070
--HG--
extra : source : 4da03e7a957c180d5997e3d8f6903b22f9a800c4
extra : intermediate-source : 28404f97bb22b726afee8df04184da81138497a2
Makes nsRemoteService responsible for managing the clients too, simplifying
nsAppRunner.
Differential Revision: https://phabricator.services.mozilla.com/D19069
--HG--
extra : source : 1ca2a56746a32219cc65015632c19a5856023e45
extra : intermediate-source : 5373c5bb9ad5bb7c3af1cae390c3612be51176b5
This code is only ever used from c++ so does not need to be an XPCOM component.
Broken out a single nsRemoteService that is responsible for choosing the server
implementation to use.
Differential Revision: https://phabricator.services.mozilla.com/D19067
--HG--
rename : toolkit/components/remote/nsDBusRemoteService.cpp => toolkit/components/remote/nsDBusRemoteServer.cpp
rename : toolkit/components/remote/nsDBusRemoteService.h => toolkit/components/remote/nsDBusRemoteServer.h
rename : toolkit/components/remote/nsGTKRemoteService.cpp => toolkit/components/remote/nsGTKRemoteServer.cpp
rename : toolkit/components/remote/nsGTKRemoteService.h => toolkit/components/remote/nsGTKRemoteServer.h
rename : toolkit/components/remote/nsXRemoteService.cpp => toolkit/components/remote/nsXRemoteServer.cpp
rename : toolkit/components/remote/nsXRemoteService.h => toolkit/components/remote/nsXRemoteServer.h
extra : source : 28c7186745e3d5de5f44a72a81e0068cb23ce547
Remoting to a different user isn't supported everywhere and being able to
remote to a different application entirely is kind of odd. I don't think it
makes sense to continue to support these operations.
Differential Revision: https://phabricator.services.mozilla.com/D19066
--HG--
extra : source : b4210f85c7e9c86ef0f173b5d2250c2862fec992
extra : intermediate-source : 35287afd3acea1602bed159dc879aa666e64b9c8
Implements the windows remove client and server based on the current remoting
code in nsNativeAppSupportWin.cpp. Makes the hidden window classname encode both
program name and profile name. nsNativeAppSupportWin is now just used for
setting up the console.
Differential Revision: https://phabricator.services.mozilla.com/D19076
--HG--
extra : rebase_source : 57d9dd30fe7df2dab104bdc15cf68467d3f56e91
Adds build config and stubs for a windows implementation of the remote client
and server.
Differential Revision: https://phabricator.services.mozilla.com/D19074
--HG--
extra : rebase_source : f33e1ad19c1ed06fc79e017d62765a7632578258
extra : source : abd7789e9637c92978efcf745361b98c5abf847a