Now that we're guaranteed to not have an existing ClientSource in the old process, we no longer need to allocate a new ClientInfo in the new process.
This lets us just create a ClientSource around the ClientInfo already on the channel (exactly as we do for same-process loads), and we no longer need to reconcile changes with the parent.
Differential Revision: https://phabricator.services.mozilla.com/D63808
--HG--
extra : moz-landing-system : lando
1. Rename mCallerDocumentURI field of PostMessageEvent to mCallerURI as we
might not always have a document, e.g. when we have a sandbox.
2. When we neither have caller's inner window (and thus we have no caller's
window ID) nor caller's URI, use script location as a source name for the error
object when reporting errors to console.
3. When the caller of postMessage has its window in a different process, pass along
the caller's window ID so that the error can be reported correctly.
Differential Revision: https://phabricator.services.mozilla.com/D59526
--HG--
extra : moz-landing-system : lando
Under some (yet) unclear conditions it's possible for a content
process to send session storage data for a browsing context that's
already been discarded. This leads to an assertion failure when
deserializing the IPC message. This commit works around this issue
by sending the browsing context's ID over IPC and issuing a warning
instead of asserting that the browsing context still exists.
Differential Revision: https://phabricator.services.mozilla.com/D59096
--HG--
extra : moz-landing-system : lando
Note that this also implicitly adds support for the view-source+srcdoc configuration, and setting of the BaseURI, which were both in the nsDocShell version but not the others.
Differential Revision: https://phabricator.services.mozilla.com/D57887
--HG--
extra : moz-landing-system : lando
Note that this also implicitly adds support for the view-source+srcdoc configuration, and setting of the BaseURI, which were both in the nsDocShell version but not the others.
Differential Revision: https://phabricator.services.mozilla.com/D57887
--HG--
extra : moz-landing-system : lando
This makes clear where the information comes from, and also that there are some
bits of information that we should pass down from the child that we don't, like
allowfullscreen and the frame name.
Differential Revision: https://phabricator.services.mozilla.com/D58535
--HG--
extra : moz-landing-system : lando
When we open a new window from a content process, we create a nested event
loop to wait for it to be initialized by the parent. The problem with this is
that the OpenWindow code which calls the window provider expects the window to
be in-process and uninitialized, so that it can load its own initial URI into
it, and correctly fulfil the spec-codified contract of window.open(). If
another caller initiates a load in the new window during the nested event
loop, those invariants are broken, and any manner of undefined behavior can
occur.
This patch adds a new flag to the BrowsingContext, marking it as uninitialized
until the end of the nested event loop, and blocking any attempts to load a
new URI into it in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D57667
--HG--
extra : moz-landing-system : lando
This doesn't solve all problems with potential reentrancy during window.open
nested event loops, but it does improve the situation somewhat. Since any
window in the same BrowsingContextGroup can target any window in the same
group, we need to suspend all windows in the group, not just the root of the
new window's parent. We also need to make sure we suspend all in-process
windows, even if we have out-of-process frames somewhere in the parent chain.
This patch takes care of suspending timeouts and input event handling in all
of these cases. It doesn't block all potential paths for running code in the
suspended windows, though, so the next patch explicitly prevents the
problematic reentrancy.
Differential Revision: https://phabricator.services.mozilla.com/D57666
--HG--
extra : moz-landing-system : lando
When we open a new window from a content process, we create a nested event
loop to wait for it to be initialized by the parent. The problem with this is
that the OpenWindow code which calls the window provider expects the window to
be in-process and uninitialized, so that it can load its own initial URI into
it, and correctly fulfil the spec-codified contract of window.open(). If
another caller initiates a load in the new window during the nested event
loop, those invariants are broken, and any manner of undefined behavior can
occur.
This patch adds a new flag to the BrowsingContext, marking it as uninitialized
until the end of the nested event loop, and blocking any attempts to load a
new URI into it in the meantime.
Differential Revision: https://phabricator.services.mozilla.com/D57667
--HG--
extra : moz-landing-system : lando
This doesn't solve all problems with potential reentrancy during window.open
nested event loops, but it does improve the situation somewhat. Since any
window in the same BrowsingContextGroup can target any window in the same
group, we need to suspend all windows in the group, not just the root of the
new window's parent. We also need to make sure we suspend all in-process
windows, even if we have out-of-process frames somewhere in the parent chain.
This patch takes care of suspending timeouts and input event handling in all
of these cases. It doesn't block all potential paths for running code in the
suspended windows, though, so the next patch explicitly prevents the
problematic reentrancy.
Differential Revision: https://phabricator.services.mozilla.com/D57666
--HG--
extra : moz-landing-system : lando
This commit implements a simple data replication scheme, where
each content process receives a copy of the relevant session
storage data when navigating, and sending all its session storage
data to the parent process before shutting down.
Differential Revision: https://phabricator.services.mozilla.com/D55662
--HG--
extra : moz-landing-system : lando