This adds a `browserId` property to all browsing contexts. This ID is the same
for the entire tree of contexts inside a frame element. Each new top-level
context created for a given frame also inherits this ID. This allows identifying
the frame element for a given browsing context.
Originally authored by :mossop in D56245.
Differential Revision: https://phabricator.services.mozilla.com/D77911
These were only used by process switches triggered via DocumentChannel, which
now take the PROCESS_BEHAVIOR_STANDARD codepath.
Differential Revision: https://phabricator.services.mozilla.com/D78973
Due to the PPDC process switching changes, we also handle switching between
remote and non-remote browsers with DocumentLoadListener. Adds support to
CanonicalBrowsingContext::ChangeFrameRemoteness to allow it to handle non-remote
browsers as well.
Differential Revision: https://phabricator.services.mozilla.com/D78971
Add a series of extra hooks and methods to allow tabbrowser to use the new
process switching codepath. This duplicates some of the logic from
`updateBrowserRemoteness` into event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D78970
This new process switching behavior is only enabled for some browser elements,
which have specified a specific attribute. Turning this on for all browsers with
a `remote` attribute causes breakage in reftests.
The initial version does not handle switching from remote to parent or
vice-versa, that is covered in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D78969
I think at this point we can remove all of RemoteWebProgressManager, some/all of the TabProgressListener recreations, and probably a bunch more.
Differential Revision: https://phabricator.services.mozilla.com/D79240
When trying to get the current focused element during reflow, when the current
focused element in the document is a frame which has yet to be initialized,
attempting to walk through that frame's BrowsingContext causes immediate frame
loader initialization. Since frame loader initialization often requires running
scripts, that's unsafe, which is why we defer initialization until the end of
any in-progress reflow or document update.
This patch fixes the focus manager code to ignore any uninitialized frame
loaders it comes across, since by definition they cannot have any
currently-focused element until their subdocuments have been created.
Differential Revision: https://phabricator.services.mozilla.com/D79392
These were only used by process switches triggered via DocumentChannel, which
now take the PROCESS_BEHAVIOR_STANDARD codepath.
Differential Revision: https://phabricator.services.mozilla.com/D78973
Due to the PPDC process switching changes, we also handle switching between
remote and non-remote browsers with DocumentLoadListener. Adds support to
CanonicalBrowsingContext::ChangeFrameRemoteness to allow it to handle non-remote
browsers as well.
Differential Revision: https://phabricator.services.mozilla.com/D78971
Add a series of extra hooks and methods to allow tabbrowser to use the new
process switching codepath. This duplicates some of the logic from
`updateBrowserRemoteness` into event handlers.
Differential Revision: https://phabricator.services.mozilla.com/D78970
This new process switching behavior is only enabled for some browser elements,
which have specified a specific attribute. Turning this on for all browsers with
a `remote` attribute causes breakage in reftests.
The initial version does not handle switching from remote to parent or
vice-versa, that is covered in a later part.
Differential Revision: https://phabricator.services.mozilla.com/D78969
Previously the BrowsingContext was also being sent down, despite it being
obvious from the PBrowserBridge actor which the message was sent over.
Differential Revision: https://phabricator.services.mozilla.com/D72929
Note that this also suppresses notifications from the initial about:blank in the new process, and updates the tabbrowser to not expect those.
Differential Revision: https://phabricator.services.mozilla.com/D65923
The new name should make it more clear that this should not be the default way
to look up the BrowsingContext instance from a nsFrameLoader, as it does not
ensure that the BrowsingContext has been fully initialized and attached to the
tree.
Differential Revision: https://phabricator.services.mozilla.com/D62959
The BrowsingContext is guaranteed to be being kept alive by
`nsFrameLoader::mBrowsingContext` and by the nsDocShell or RemoteBrowser object.
This improves the ergonomics of this helper method, which may help avoid misuse
of `mBrowsingContext`.
Differential Revision: https://phabricator.services.mozilla.com/D62957
CLOSED TREE
Backed out changeset d6fd08e3fccf (bug 1615480)
Backed out changeset ad31eae54af2 (bug 1615480)
Backed out changeset 70aff2593d98 (bug 1615480)
The new name should make it more clear that this should not be the default way
to look up the BrowsingContext instance from a nsFrameLoader, as it does not
ensure that the BrowsingContext has been fully initialized and attached to the
tree.
Differential Revision: https://phabricator.services.mozilla.com/D62959
The BrowsingContext is guaranteed to be being kept alive by
`nsFrameLoader::mBrowsingContext` and by the nsDocShell or RemoteBrowser object.
This improves the ergonomics of this helper method, which may help avoid misuse
of `mBrowsingContext`.
Differential Revision: https://phabricator.services.mozilla.com/D62957
There are all sorts of lifecycle issues which arise from making DocShell
responsible for discarding BrowsingContexts. In this particular bug, we tend
to run into them in cases where we create a BrowsingContext for a FrameLoader,
and then never create a DocShell for it, leading to it never being destroyed.
But there are myriad other issues as well.
This patch moves the responsibility for BrowsingContext lifecycle management
to the FrameLoader/FrameLoaderOwner, rather than the DocShell, which makes
things more consistent, and more closely aligns with spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D59008
This doesn't block the STATE_START notification from the new process, as we currently have a second start notification (when DocumentChannel redirects to the real channel), so this is unchanged.
Differential Revision: https://phabricator.services.mozilla.com/D56818
If these are fired too early, a nested event loop can be spun before the new
nsFrameLoader has been set up. Messages can be received over the
BrowserBridgeChild actor during this time when no nsFrameLoader is set, causing
crashes.
Differential Revision: https://phabricator.services.mozilla.com/D49647
If these are fired too early, a nested event loop can be spun before the new
nsFrameLoader has been set up. Messages can be received over the
BrowserBridgeChild actor during this time when no nsFrameLoader is set, causing
crashes.
Differential Revision: https://phabricator.services.mozilla.com/D49647
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
This flips the direction in which the BrowserBridge actor is generally created
such that it is generally created in the parent and sent down to a child
process.
This is done by making the decision about what kind of switch to perform in the
parent, and sending messages down to child processes async to orchestrate these
process changes.
Process launching is changed to use an async `MozPromise`-returning API in this
patch, though the actual process launching still occurs synchronously. A future
patch will enable performing async process launching through the
NewOrUsedBrowserProcess mechanism.
I know of at least a few timing issues which exist with the new logic,
especially around the state of the BrowsingContext during the process
transition. I decided to not try to fix all of these issues in this patch, as
many are complex and will require changing how we manage the lifecycle of
BrowsingContext substantially. I do, however, think that the new logic is more
reliable and has fewer timing issues than the previous logic.
Differential Revision: https://phabricator.services.mozilla.com/D47310
This fixes both our failure to register load blockers for remote frames and
our failure to keep the load event blocked during frameloader rebuilding on
remoteness change.
Differential Revision: https://phabricator.services.mozilla.com/D46503
This patch changes a few things about how nsFrameLoader is created, specifically
around the ChangeRemoteness API.
1. The private 'nsFrameLoader::nsFrameLoader' constructor has been simplified to
only have one overload, shared by the different `::Create` static methods.
2. The creation static method used by `ChangeRemoteness` has changed name to
`::Recreate`, as the signature is becoming more like the old method.
3. The `mNetworkCreated` bit is preserved when doing a `ChangeRemoteness`, as a
remoteness change shouldn't be affecting that property.
4. Unused fields are removed from the ChangeRemoteness API.
5. The `remoteType` attribute is now mandatory in the ChangeRemoteness API,
which simplifies the logic and makes it harder to accidentally misuse.
Differential Revision: https://phabricator.services.mozilla.com/D44893
This requires replacing inclusions of it with inclusions of more specific prefs
files.
The exception is that StaticPrefsAll.h, which is equivalent to StaticPrefs.h,
and is used in `Codegen.py` because doing something smarter is tricky and
suitable for a follow-up. As a result, any change to StaticPrefList.yaml will
still trigger recompilation of all the generated DOM bindings files, but that's
still a big improvement over trigger recompilation of every file that uses
static prefs.
Most of the changes in this commit are very boring. The only changes that are
not boring are modules/libpref/*, Codegen.py, and ServoBindings.toml.
Differential Revision: https://phabricator.services.mozilla.com/D39138
Still having lots of issues with tests failing, but need to get this
landed for various reasons. Followup to pref on at Bug 1550571.
Differential Revision: https://phabricator.services.mozilla.com/D30563
