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
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
