This requires adding the flag as a synced field on the BrowsingContext, and
checking it in a few more places. Attempts to open a new window in this racy
manner will now raise an exception.
This should avoid the issue from bug 1658854 by blocking the buggy attempts to
load before the nested event loop has been exited.
Differential Revision: https://phabricator.services.mozilla.com/D87927
This has couple of different pieces and one may want to focus on each of those separately when
reviewing. The first two as small changes.
- Moving mDynamicallyCreated from nsDocShell to be a sync'ed field on BrowsingContext.
CanonicalBrowsingContext::CreateLoadingSessionHistoryEntryForLoad sets that on a newly created entry.
- Adding mActiveEntryIsLoadingFromSessionHistory. mLoadingEntry + mActiveEntryIsLoadingFromSessionHistory has roughly
the same lifetime as mLSHE. mLoadingActiveEntry is needed so that child docshell can know whether its parent is loading from session history.
- The main part is in MaybeHandleSubframeHistory which checks if the parent docshell is loading from session history,
and if so, asks for a LoadingSessionHistoryInfo. In the case of docshell living in a child process that operation is asynchronous,
so when the data is back from the parent process, LoadURI is called again with the possibly updated data.
One could possibly split the code to smaller methods and then deal with aContinueHandlingSubframeHistory only in LoadURI,
but MaybeHandleSubframeHistory does have some early returns which would make that approach possibly hard to follow.
Differential Revision: https://phabricator.services.mozilla.com/D89685
Need to mark entries as being loading sooner, since HandleSameDocumentNavigation case doesn't do the round trip through parent again.
And HandleSameDocumentNavigation needs to update active entry and inform parent that is has dealt with the load.
Differential Revision: https://phabricator.services.mozilla.com/D89837
ChildSHistory.legacySHistory isn't valid for content processes when
session history in the parent is enabled. We try to fix this by either
delegating to the parent by IPC or move the implementation partially
or as a whole to the parent.
Differential Revision: https://phabricator.services.mozilla.com/D89353
Mostly mechanical changes, with some work needed to convert the different payloads (with optional timestamps, inner window id, and/or backtrace) to the equivalent MarkerOptions.
Differential Revision: https://phabricator.services.mozilla.com/D89587
This patch enables sandboxed srcdoc loads to take place via DocumentChannel,
and adds mechanisms for enabling unsandboxed ones.
Both unsandboxed srcdoc, and in subsequent patches, about:blank, loads require
that the triggering principal and the principal to inherit point to the same
instance if the load takes place in the same process as where we are inheriting
those principals from. We save those principals on a target browsing context before
we load the URI, and later, when we are deserializing LoadInfoArgs into
LoadInfo in the content process, we retrieve the saved principals if the
current load identifier of the target BC matches the load identifier saved
along with the principals.
We also need to make sure that during a process switch for about:srcdoc load,
we don't use the original URI for about:srcdoc to determine the remote type and
instead we use channel's result principal.
Differential Revision: https://phabricator.services.mozilla.com/D85079
This centralizes our print and preview setup in nsGlobalWindowOuter so
that we never re-clone a clone, and so that we reuse the window.open()
codepath to create the browsing context to clone into.
For window.print, for both old print dialog / silent printing and new
print preview UI, we now create a hidden browser (as in with visibility:
collapse, which takes no space but still gets a layout box).
* In the modern UI case, this browser is swapped with the actual print
preview clone, and the UI takes care of removing the browser.
* In the print dialog / silent printing case, the printing code calls
window.close() from nsDocumentViewer::OnDonePrinting().
* We don't need to care about the old print preview UI for this case
because it can't be open from window.print().
We need to fall back to an actual window when there's no
nsIBrowserDOMWindow around for WPT print tests and the like, which don't
have one. That seems fine, we could special-case this code path more if
needed but it doesn't seem worth it.
Differential Revision: https://phabricator.services.mozilla.com/D87063
Checking for an nsISHEntry doesn't work anymore with session history in the
parent. For that we can check that the loading session history info's
mIsLoadFromSessionHistory is true. If there is no loading session history info
we can fall back to the old way of checking for a non-null nsISHEntry (which
will only ever be true if session history in the parent is turned off).
Differential Revision: https://phabricator.services.mozilla.com/D87037
There is the same information exposed in DocShellLoadStateInit.
And we don't really need to query user action from BrowsingContext, this
information would be carried in `nsDocShellLoadState`.
Depends on D86724
Differential Revision: https://phabricator.services.mozilla.com/D86773
SessionHistoryEntry::MaybeSynchronizeSharedStateToInfo call is a tad controversial, but
something like that is needed for the cases when the actual value lives in the SHEntrySharedParentState.
Differential Revision: https://phabricator.services.mozilla.com/D86640
