The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
The `category.WithOptions(...)` syntax was a bit strange and difficult to explain.
Now the category and options are separate parameters. Default options can be specified with `MarkerOptions{}` or just `{}`.
As a special case, defaulted-NoPayload functions don't need `<>`, and defaulted-NoPayload functions and macros don't even need `{}` for default options, e.g.:
`profiler_add_marker("name", OTHER); PROFILER_MARKER_UNTYPED("name", OTHER);`
Differential Revision: https://phabricator.services.mozilla.com/D91680
This should make it work on fission, plus is simpler than the
alternative of traversing the whole docshell tree and then undo it.
It also is going to make easier the actual fix for this bug.
Differential Revision: https://phabricator.services.mozilla.com/D91438
document.open replaces the session history entry with a new one, the url of
which needs to point to the entry document. nsDocShell::UpdateActiveEntry wasn't
resetting the url and the originalURL in the replace case. This patch always
creates a new SessionHistoryInfo so we share more code between replace and
non-replace, to avoid missing some fields.
Differential Revision: https://phabricator.services.mozilla.com/D91273
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
