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
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.
***
Format cleanup
Differential Revision: https://phabricator.services.mozilla.com/D19697
--HG--
extra : moz-landing-system : lando
BasicDllServices is used to gain access to the authenticode APIs in non-Gecko
contexts. One feature that WinDllServices provides is the ability to register
a callback interface to be notified when a DLL has been loaded.
This is not particularly useful in the BasicDllServices use case, and in the
"handle a launcher process failure on a background thread" use case, would
actually be harmful.
This patch modifies the DLLServices backend to offer a "basic" option that
omits the callback stuff.
Differential Revision: https://phabricator.services.mozilla.com/D19696
--HG--
extra : moz-landing-system : lando
We use the SHIELD pref instead of the usual launcher process pref for Nightly.
This effectively treats the launcher process as a SHIELD study with 100%
deployment.
We add some Nightly-specific code that uses the SHIELD pref to determine
whether or not to use the launcher. During startup, we query that pref and
reflect it into the registry, which then falls through to the usual launcher
process code.
We will be changing this past 67, but for now this is an effective way to
provide Nightly users with an opt-out to the launcher process and its telemetry.
Differential Revision: https://phabricator.services.mozilla.com/D20621
--HG--
extra : moz-landing-system : lando
Set the updater LDFLAGS to -Wl,-rpath=$ORIGIN so NSS can be found in the binary's directory
Stop changing the LD_LIBRARY_PATH in nsUpdaterDriver.cpp
Load the updater support files before the update begins in progressui_gtk.cpp
Launch the updater from the install directory instead of copying it to the update directory
Remove the skip-if = (os == linux && verify) for the staging tests since this also fixes the ETXTBSY error when calling execv on the copied updater
Differential Revision: https://phabricator.services.mozilla.com/D20098
--HG--
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
This patch takes care of a bunch of issues and does some cleanup:
* We rename mscom::MainThreadRuntime to mscom::ProcessRuntime, as the latter
is a more accurate name going forward.
* We make ProcessRuntime aware of the Win32k Lockdown process mitigation
policy. When Win32k is disabled, we perform process-wide COM initialization
in the multi-threaded apartment (since we cannot create an STA window).
* We refactor the mscom apartment region stuff to enable the Win32k lockdown
pieces in ProcessRuntime.
* We move some Gecko-specific stuff into MOZILLA_INTERNAL_API guards so that
ProcessRuntime is usable outside of xul.dll (I will be needing it for the
launcher process).
* Another thing that might happen with the launcher process is that, under
error conditions in the launcher, we create a ProcessRuntime object on a
background thread for the purposes of telemetry logging, but we also allow
the main thread to proceed to start as the browser. This could result in a
scenario where the main thread, as the browser process, is attempting to
instantiate its ProcessRuntime and ends up racing with the launcher process's
telemetry thread which has its own ProcessRuntime. To account for this
situation, we add mutual exclusion to the process-wide initialization code.
We host this part inside mozglue since that state is shared between both
firefox.exe and xul.dll.
* We clean up ProcessRuntime::InitializeSecurity by using Vector to set up
the EXPLICIT_ACCESS entries.
* We remove mscom::MainThreadClientInfo and replace it with a direct call to
CoGetCallerTID
* We revise all references to this class to use the new name.
Differential Revision: https://phabricator.services.mozilla.com/D19551
--HG--
rename : ipc/mscom/COMApartmentRegion.h => ipc/mscom/ApartmentRegion.h
rename : ipc/mscom/MainThreadRuntime.cpp => ipc/mscom/ProcessRuntime.cpp
rename : ipc/mscom/MainThreadRuntime.h => ipc/mscom/ProcessRuntime.h
extra : moz-landing-system : lando
Currently we only check and remove the --allow-downgrade command line argument
if the run is actually a downgrade. When we don't the --allow-downgrade argument
makes it to Firefox's default command line handler which doesn't know how to
handle it and so ignores it and the next argument on the command line.
Flipping the ordering of the check makes sure we always remove the argument.
Differential Revision: https://phabricator.services.mozilla.com/D19569
--HG--
extra : moz-landing-system : lando
Currently we only check and remove the --allow-downgrade command line argument
if the run is actually a downgrade. When we don't the --allow-downgrade argument
makes it to Firefox's default command line handler which doesn't know how to
handle it and so ignores it and the next argument on the command line.
Flipping the ordering of the check makes sure we always remove the argument.
Differential Revision: https://phabricator.services.mozilla.com/D19569
--HG--
extra : rebase_source : 9d92c78a500bccdcb05d002bb129e779d2391468
So the remoting clients can know what the selected profile is before an attempt
to lock it is made we move the locking code to after the call to SelectProfile.
Differential Revision: https://phabricator.services.mozilla.com/D19420
--HG--
extra : moz-landing-system : lando
