98
edits
Platform/Integration/InjectEject/Launcher Process/: Difference between revisions
Platform/Integration/InjectEject/Launcher Process/ (view source)
Revision as of 21:42, 24 July 2019
, 24 July 2019no edit summary
No edit summary |
No edit summary |
||
| Line 40: | Line 40: | ||
* Over the course of a Firefox browsing session, the launcher process lies 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. | * Over the course of a Firefox browsing session, the launcher process lies 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. | ** 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! | ||
* This would not work with the scenario where an elevated launcher process asks Explorer to restart the browser as a normal user; Explorer does not return any process ID or handle information to the launcher process, so there is nothing for the launcher process to wait on. This would introduce an undesirable inconsistency in the command-line behavior of the launcher process. By explicitly opting into waiting for the browser process, the launcher process adjusts its behavior to avoid this scenario, but uses a less desirable mechanism for restarting the browser. | * This would not work with the scenario where an elevated launcher process asks Explorer to restart the browser as a normal user; Explorer does not return any process ID or handle information to the launcher process, so there is nothing for the launcher process to wait on. This would introduce an undesirable inconsistency in the command-line behavior of the launcher process. By explicitly opting into waiting for the browser process, the launcher process adjusts its behavior to avoid this scenario, but uses a less desirable mechanism for restarting the browser. | ||