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
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 : rebase_source : 352d2e315fdd12b8da71358f364ce2789f7c8b99
extra : intermediate-source : 8e3c52953f837769e632d8b7d2d7fbc195df375e
extra : source : f1f569797e33b390ba588351e826fa979b018f01
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 : rebase_source : c83f6795ce58019390feaf918045c24527da543e
extra : intermediate-source : 48c797da72052953b4a81648219750914846e162
extra : source : 5c648e7641a72770d89a5408ac01de3b5de15c6b
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 : rebase_source : d2191966989c1b6db0dfb0db91f1b27d85046835
extra : intermediate-source : 405ea32162ba129b0c3e9ed75c9de13259d2d759
extra : source : 4da03e7a957c180d5997e3d8f6903b22f9a800c4
Makes nsRemoteService responsible for managing the clients too, simplifying
nsAppRunner.
Differential Revision: https://phabricator.services.mozilla.com/D19069
--HG--
extra : rebase_source : a5a8dc33b8b871a0b01e802bb406383275ddd4ec
extra : intermediate-source : c8bd4a7bc4e04b3648395252d4a377feb237e58e
extra : source : 1ca2a56746a32219cc65015632c19a5856023e45
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 : rebase_source : 631ee45923c64acde92e23c155cbbbbc7a1d9c4d
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 : rebase_source : df03e6d2233c4235308f2f8c8ec860e8827254e5
extra : source : b4210f85c7e9c86ef0f173b5d2250c2862fec992
Counting CPUs accesses the filesystem (sysfs or procfs), which we'd like
to disallow when sandboxed if possible, and fails silently if access
is denied. Because the CPU count rarely changes, this patch handles
that problem for the RDD process by caching a copy before starting
sandboxing.
Tested with a local patch to have the sandbox file broker client crash
if accessing the sysfs node for the CPU count, to verify that it's not
accessed.
Depends on D14524
Differential Revision: https://phabricator.services.mozilla.com/D20895
--HG--
extra : moz-landing-system : lando
This patch does a few things:
* Fleshes out the launcher process failure ping;
* Sends that ping via pingsender;
* If there is any failure in doing so, we fall back to the Windows event log;
* Any launcher process failures will result in us falling back to the normal
startup code path, ensuring that users will still see a browser.
A sample ping will be attached to the bug.
Differential Revision: https://phabricator.services.mozilla.com/D19697
--HG--
extra : moz-landing-system : lando
