canmove, Confirmed users, Bureaucrats and Sysops emeriti
4,714
edits
Platform/Integration/InjectEject/Launcher Process/: Difference between revisions
Jump to navigation
Jump to search
Platform/Integration/InjectEject/Launcher Process/ (view source)
Revision as of 08:50, 10 May 2022
, 10 May 2022→Starting Firefox via Automation / Scripting: It also applies for the `remote-debugging-port` command line argument
No edit summary |
(→Starting Firefox via Automation / Scripting: It also applies for the `remote-debugging-port` command line argument) |
||
| (4 intermediate revisions by 2 users not shown) | |||
| Line 12: | Line 12: | ||
* It must recover gracefully from failures; | * It must recover gracefully from failures; | ||
* Its code must be self-contained inside <code>firefox.exe</code>; | * Its code must be self-contained inside <code>firefox.exe</code>; | ||
* Its code cannot start nor rely on prefs, XPCOM, <code>nsString</code>, crash reporter, or other aspects of the Gecko runtime. Header-only code that does not depend on <code>xul.dll</code> (such as | * Its code cannot start nor rely on prefs, XPCOM, <code>nsString</code>, crash reporter, or other aspects of the Gecko runtime. Header-only code that does not depend on <code>xul.dll</code> (such as MFBT) is safe to use in the launcher process; | ||
* Some parts of its code must be freestanding -- that is, those parts cannot assume the presence of either the C runtime or the Win32 API. | * Some parts of its code must be freestanding -- that is, those parts cannot assume the presence of either the C runtime or the Win32 API. | ||
| Line 33: | Line 33: | ||
* Firefox is started with the <code>-marionette</code> command line option; | * Firefox is started with the <code>-marionette</code> command line option; | ||
* Firefox is started with the <code>-headless</code> command line option; | * Firefox is started with the <code>-headless</code> command line option; | ||
* Firefox is started with the <code>-remote-debugging-port</code> command line option; | |||
* Firefox is started with the <code>MOZ_AUTOMATION</code> environment variable set; | * Firefox is started with the <code>MOZ_AUTOMATION</code> environment variable set; | ||
* Firefox is started with the <code>MOZ_HEADLESS</code> environment variable set; | * Firefox is started with the <code>MOZ_HEADLESS</code> environment variable set; | ||
| Line 38: | Line 39: | ||
'''''Why does the Launcher Process not wait for the browser by default?''''' | '''''Why does the Launcher Process not wait for the browser by default?''''' | ||
* Over the course of a Firefox browsing session, the launcher process | * Over the course of a Firefox browsing session, the launcher process would lie dormant and its private virtual memory would eventually be paged out to disk. However, it would still be visible as yet another <code>firefox.exe</code> process in the operating system's process list. | ||
** To avoid the launcher process being charged against Firefox's overall resource usage (and the public perceptions that doing so would entail), we let the launcher process exit. | ** To avoid the launcher process being charged against Firefox's overall resource usage (and the public perceptions that doing so would entail), we let the launcher process exit. | ||
** We also do not want launcher process VM to be unnecessarily occupying space in the page file on machines where there is limited page file space. This is not uncommon - see our various OOM crash reports if you don't believe it! | ** We also do not want launcher process VM to be unnecessarily occupying space in the page file on machines where there is limited page file space. This is not uncommon - see our various OOM crash reports if you don't believe it! | ||
| Line 57: | Line 58: | ||
== Other Troubleshooting == | == Other Troubleshooting == | ||
If the launcher process fails and telemetry is enabled, the launcher process generates and sends a telemetry ping containing an error code and the source code location of the failure. If telemetry is disabled, or if for some reason the launcher process was unable to successfully send its telemetry ping, the launcher process will log the failure to the Windows event log. | If the launcher process fails and telemetry is enabled, the launcher process generates and sends [https://firefox-source-docs.mozilla.org/toolkit/components/telemetry/data/launcher-process-failure-ping.html a telemetry ping] containing an error code and the source code location of the failure. If telemetry is disabled, or if for some reason the launcher process was unable to successfully send its telemetry ping, the launcher process will log the failure to the Windows event log. | ||
The submitted telemetry is available in [https://iodide.telemetry.mozilla.org/notebooks/219/?viewMode=report this dashboard]. It's important to keep the failure numbers low. | |||
To view launcher process failure events in the system event viewer, open the <code>Control Panel</code> [''Note: this must be the legacy <code>Control Panel</code> app, not the new <code>Settings</code> app found in Windows 8 and Windows 10''], select <code>Administrative Tools</code>, and double-click on <code>Event Viewer</code>. Looking at the tree in the left pane, expand the <code>Windows Logs</code> branch, and click <code>Application</code>. | To view launcher process failure events in the system event viewer, open the <code>Control Panel</code> [''Note: this must be the legacy <code>Control Panel</code> app, not the new <code>Settings</code> app found in Windows 8 and Windows 10''], select <code>Administrative Tools</code>, and double-click on <code>Event Viewer</code>. Looking at the tree in the left pane, expand the <code>Windows Logs</code> branch, and click <code>Application</code>. | ||
It is also possible to force the launcher process to always log failures to the Windows event log by adding the <code>-log-launcher-error</code> option to the command line. This may be useful when assisting specific users who are experiencing launcher process failures. | It is also possible to force the launcher process to always log failures to the Windows event log by adding the <code>-log-launcher-error</code> option to the command line. This may be useful when assisting specific users who are experiencing launcher process failures. | ||