This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
This change adds the ground work to share content provided by the JS engine of
the Parent process to initialize the JS engine of other threads and Content
processes.
The singleton class xpc::SelfHostedShmem is used to wrap the logic behind
holding the memory. The memory is initialized with `InitFromParent` or
`InitFromChild`. The memory is accessible using either the `Content` or
`Handle`.
The shared memory is transfered through the command line using
`mozilla::ipc::ExportSharedJSInit` and read using
`mozilla::ipc::ImportSharedJSInit` functions. The command line is used, as we
need the shared memory to be avilable for the JS engine initialization. The
command line is composed of a single command named `-jsInit` which is followed
by the handle (on Windows) and the length of the shared content.
The memory associated with the shared memory is cleared in `ShutdownXPCOM` after
closing all threads, and shuting down the JS engine. This is necessary as we
expect the JS engine to borrow content from the shared memory.
Differential Revision: https://phabricator.services.mozilla.com/D110576
This should help avoid crashes caused when the content process has
already destroyed a BCG when the parent process hasn't yet. The BCG will
still be destroyed when the content process shuts down using normal
cycle-collection.
Differential Revision: https://phabricator.services.mozilla.com/D113828
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
This is the second of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support.
Differential Revision: https://phabricator.services.mozilla.com/D107150
This is the first of two patches in this series that removes a large amount of now dead code from dom/plugins as part of removing all NPAPI plugin support. This patch removes re-entrancy guards we have for Windows OnPaint messages, as the guards were only needed for windowed plugins.
Differential Revision: https://phabricator.services.mozilla.com/D107144
This patch contains a large number of changes around the process switching
mechanism in order to avoid issues which are caused by a mismatched
understanding of the state of the process switch between processes in the
presence of nested event loops.
This includes:
1. The "InFlightProcessId" value is no longer recorded. All remaining uses
were removed in part 1, and the new mechanism tracks this information in
a better way.
2. The current BrowserParent instance is now tracked on
CanonicalBrowsingContext, meaning that logic which needs to work with this
information can now access it without depending on the current
WindowGlobalParent instance.
3. When doing a process switch, the previous host process for the
BrowsingContext is tracked until the process switch is completed, allowing
for future attempts to switch into that process to be delayed until the
previous unload event has finished running.
4. The process switch logic was refactored to simplify some of the
error-handling logic, and share more code between different cases.
Differential Revision: https://phabricator.services.mozilla.com/D110002
This patch contains a large number of changes around the process switching
mechanism in order to avoid issues which are caused by a mismatched
understanding of the state of the process switch between processes in the
presence of nested event loops.
This includes:
1. The "InFlightProcessId" value is no longer recorded. All remaining uses
were removed in part 1, and the new mechanism tracks this information in
a better way.
2. The current BrowserParent instance is now tracked on
CanonicalBrowsingContext, meaning that logic which needs to work with this
information can now access it without depending on the current
WindowGlobalParent instance.
3. When doing a process switch, the previous host process for the
BrowsingContext is tracked until the process switch is completed, allowing
for future attempts to switch into that process to be delayed until the
previous unload event has finished running.
4. The process switch logic was refactored to simplify some of the
error-handling logic, and share more code between different cases.
Differential Revision: https://phabricator.services.mozilla.com/D110002
Similarly to the old session history implementation, scroll position needs to be stored in HandleSameDocumentNavigation.
The relevant old implementation is couple of lines above the new code in nsDocShell.
Differential Revision: https://phabricator.services.mozilla.com/D109756
This is the start of an actor which will be automatically instantiated in the
parent and each content process which can be used to route most process-level
IPC traffic needed by the extensions framework. It should allow the extensions
framework to keep its IPC glue close to the code that uses it, and simplify
matters for child-side code which needs to run in both parent and content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D103212
This is the start of an actor which will be automatically instantiated in the
parent and each content process which can be used to route most process-level
IPC traffic needed by the extensions framework. It should allow the extensions
framework to keep its IPC glue close to the code that uses it, and simplify
matters for child-side code which needs to run in both parent and content
processes.
Differential Revision: https://phabricator.services.mozilla.com/D103212