In order to use `mscom::ProcessRuntime` in the maintenance service, we need
`ProcessRuntime` to be able to distinguish between more than just whether or not
the current process is the parent process.
I've added a new `ProcessCategory` enum to track this information, and revised
the constructors so that we now have one that accepts a ProcessCategory.
The `ProcessCategory` constructor is private inside XUL, since the
`GeckoProcessType` variant should always be used in that case.
We also slightly change apartment initialization to depend on the underlying
`ProcessCategory` value.
Finally, I modify the one case where we instantiate a `ProcessRuntime` in the
launcher process to use the new constructor.
Differential Revision: https://phabricator.services.mozilla.com/D42225
--HG--
extra : moz-landing-system : lando
If we are running a background thread in the launcher process to log failures,
then allowing the main thread to proceed with monkeypatching system calls is a
Bad Idea. This patch gives us an environment variable that, when set, indicates
that it is unsafe for PoisonIOInterposer to run.
This scenario is an uncommon one, but one that we must account for nonetheless.
Differential Revision: https://phabricator.services.mozilla.com/D21607
--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
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
This patch does a couple of things:
* I added a new class, |WindowsError| to WinHeaderOnlyUtils. The idea here is
to encapsulate as much of the Windows error gamut as possible into one class.
Since Win32 errors and NTSTATUS codes may both be encoded as HRESULTs, I
used the latter type to store the error. It also contains functions for
converting between the various error code formats, as well as stringification
via FormatMessage.
* I added |LauncherError| which also includes file and line number information,
which I believe will be important for launcher process failure diagnostics.
(Instantiation of LauncherErrors obviously must be done via macros to capture
__FILE__ and __LINE__).
* I then converted all of the launcher process code (and its few depenencies) to
utilize this new functionality via the new |LauncherResult| type.
* If we detect an error in one of the top-level launcher process functions, we
pass it to |HandleLauncherError| for processing. This function currently just
throws up a |MessageBox| like the previous code did, with the intention of
enhancing that further in the future.
Differential Revision: https://phabricator.services.mozilla.com/D12365
--HG--
extra : moz-landing-system : lando
