The patch is utilizing SHistoryChangeNotifier which was added for testing.
CallerWillNotifyHistoryIndexAndLengthChanges is needed to avoid extra index/length updates so that
the child side doesn't get update but have still pending updates in it.
Differential Revision: https://phabricator.services.mozilla.com/D91756
This works, though probably we want to do some follow-up tweaks, like
the adding of the onload blocker and so on, so that we can avoid the
UpdateDimensions hack.
We may also want a PrintObject in the nsPrintJob tree, perhaps...
Differential Revision: https://phabricator.services.mozilla.com/D90310
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
As we want to have an ability to do different operations on different browsing contexts for those actions with default handlers (play/pause/stop), so in D87142 we have changed `ContentMediaController` per browsing context. Techically it's per inner window, but it means each browsing context would have one corresponding `ContentMediaController` if the web content is in that browsing context.
The approach to achieve the goal is that, when getting those actions, we would notify to the top level browsing context, then go through its children to ensure that each browsing context can be operated correctly. By doing so, we can trigger default action handler and customized action handler on different browsing context.
Eg. A page has a child iframe, which has active media session with an action handler for `pause`. A page and iframe are both playing media. When pressing `pause`, default action handler would be run on main frame, and the customized action handler would be run on iframe.
Differential Revision: https://phabricator.services.mozilla.com/D87143
