When adding a new entry while handling popstate, this would go
throught the paremeterized version of AddPendingHistoryChange, which
doesn't re-compute length which would result in an error in
history.length.
Differential Revision: https://phabricator.services.mozilla.com/D92393
This patch fixes two issues, described below:
First, the GetTopLevelDocument function was looking at the browsing
context tree. It should look at the window context tree, as looking at
the browsing context tree means that if you're in a discarded or
about-to-get-discarded document, you can end up with a document from a
different tree. Computing intersections between those of course makes no
sense and triggers the assertion we're enabling.
Second, this patch fixes an issue when you have fission enabled, and a
setup such as:
A1 -> B1 -> A2
If you try to use IntersectionObserver from A2 with the implicit root,
we'd end up with:
* rootRect: A1's root scrollport rect (this is fine, because it's only
used to compute the root margin and bounds and so on, not
to compute geometry).
* rootFrame: A1's root scroll frame (this is _not_ fine, see below).
Then, we'd try to map rects from A2's target to A1's viewport, and we
can't really do that sensibly with the existing nsLayoutUtils functions,
because we're not accounting for all the OOP iframe transforms that may
be going on. This also triggers the assertion that this patch enables in
same-origin-grand-child-iframe.sub.html.
To fix it, for the A2 case, use the same code that we have for other OOP
iframes. The test tweaks fails with fission enabled without the patch
(because we don't account for the OOP iframe clip).
Differential Revision: https://phabricator.services.mozilla.com/D92089
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
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
In many cases with wpt, most of the tests in the file pass, but it is rather time consuming to annotate
.ini files case by case.
Differential Revision: https://phabricator.services.mozilla.com/D91977
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
This was only being checked on OnDonePrinting() which isn't called in
the original docshell. Move it to the window because we don't need to
care about document viewers getting closed during print operations,
they're top level browsers that don't run script.
Differential Revision: https://phabricator.services.mozilla.com/D91416
Before Quantum, we needed resizer icon on Windows, because when the
add-on statusbar was hidden, we could not resize the window. This is not
needed anymore and is dead code. Consequentially, this also helps reduce
unused images loaded at startup time.
Differential Revision: https://phabricator.services.mozilla.com/D91196
We would like to remove `page_had_media_count` and use a new probe `in_page_count` to record the total number of top level content documents using media.
Therefore, we would rename WindowContext's `DocTreeHadAudibleMedia` to `DocTreeHadMedia` in order to support the new usage.
In the future, if we want to know something like "the percentage of media element is being used for MSE/EME?", then this scalar can be the base and used to calculate the answser.
Differential Revision: https://phabricator.services.mozilla.com/D83225
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 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 adds a rate limit to methods and setters of the History and Location
for non-system callers.
The rate limit is counted per BrowsingContext and can be controlled by prefs.
This patch is based on the original rate limit patch by :freesamael.
Differential Revision: https://phabricator.services.mozilla.com/D90136
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
With fission enabled, when we are starting a load, we might be saving
principals for a specific browsing context in process A, and then end up
targetting process B for the load, so during deserialization of the
LoadInfoArgs struct, we will end up using principals that were saved during a
previous load targetting that browsing context (with the same id) but in
process B.
Therefore, we cannot assert (without clearing the saved principals in the
original browsing context when a load is done, which can be done as a follow up
work) that the saved principal will be equal to the serialized one from
LoadInfoArgs.
Differential Revision: https://phabricator.services.mozilla.com/D89728
The race occurs when the parent changes the owner process for a BC, but the
child does not know about it and proceeds to call SetCurrentInnerWindowId on a
BC it no longer owns. To fix this, in child process, whenever we call
SetCurrentInnerWindowId on a BC, check that the BC is in process and that the
docshell has not been notified about an upcoming process change.
Differential Revision: https://phabricator.services.mozilla.com/D87934
Creating more than 2 nested iframes is not allowed and is now enforced for
about:blank loads because they now take place via DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D85084
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
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
We determine which media session is active media session in chrome process, but the media session in content process doesn't know the detail.
This patch would store the active session context Id on the top level WindowContext, so that media session in content process can know if it's an active context or not, which helps to trigger the action handler only on active media session, after changing our propagation mechanism in following patches.
Differential Revision: https://phabricator.services.mozilla.com/D88106
Other engines also do this, but with my previous patch breaks it
(because we only hit print() on the print-content-viewer _after_ doing
the clone).
So move it before triggering all the machinery, and only for
window.print(). Given we didn't check this for print preview etc, I
think it's fine to carry on for user-triggered loads.
Trivial test-case (which I'm not quite sure how to turn into an
automated test...)
<!doctype html>
<h1>I do get printed but...</h1>
<script>
window.print();
</script>
<h2>Do I?</h2>
Note that this is broken with the new print preview UI already, this
fixes it.
Differential Revision: https://phabricator.services.mozilla.com/D87898
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
The entries in the parent process stores some data in a shared state for some of
the entries that share a document. We also need to store some of this data in
the info objects in the child process, but it doesn't make sense to have it be
shared: the data shouldn't be mutated in the child process, and we probably only
have one of the info objects anyway. This adds a structure that holds the shared
data for an info object in the child process, but without actually sharing it.
As we use info objects in both parent and child, we hold a void pointer that's a
strong reference to a shared state in the parent process, and an owning pointer
to the pseudo-shared state in the child process.
Differential Revision: https://phabricator.services.mozilla.com/D87038
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
Do this by spinning the event loop until we've done the clone for
preview as appropriate.
This should be much less risky than finishing the previous patches
which would still be nice, but realistically landing them for 81 is not
going to happen.
This just returns without doing nothing in a couple cases, like when
there's already another modal dialog or such. That seems acceptable to
me, it's not clear what better way to do would be.
Differential Revision: https://phabricator.services.mozilla.com/D87484
If we're after shutdown, then this variable will have been cleared.
This is the remaining use that was failing to do a null check, and
it was manifesting as a very low-volume crash.
Differential Revision: https://phabricator.services.mozilla.com/D87503
It has some properties which make it footgunny, especially in the face of
Fission. Callers should use WindowGlobalChild.innerWindowId instead.
Differential Revision: https://phabricator.services.mozilla.com/D82801
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
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
Popup permissions initialized with the result of checking if the
constructing WindowContext's principal is allowed to open a popup. The
field is updated for all WindowContexts sharing a principal whenever
the popup permission for that nsIPrincipal changes.
Differential Revision: https://phabricator.services.mozilla.com/D86378
A new `BrowsingContext` field, `isActiveBrowserWindow`, has been added
to track the active browser window for the `:-moz-window-inactive`
pseudoclass. This field takes the place of
`nsPIDOMWindowOuter::mIsActive`.
With this change `:-moz-window-inactive` is now fission compatible.
Differential Revision: https://phabricator.services.mozilla.com/D86422
We currently start with screen-relative coordinates, translate them to
widget-relative coordinates, and then translate them back to screen-relative
coordinates when actually showing the tooltip in XULBrowserWindow.showTooltip().
There's no reason for the extra conversions, so we can just send screen-relative
coordinates directly.
Since the widget origin for out-of-process frames is the origin of the frame
itself (instead of the tab, which is the case for in-process frames), the
screen-to-widget conversion was incorrect, and was causing a bug in how the
tooltip was being positioned. Avoiding that conversion altogether also fixes
that bug.
Differential Revision: https://phabricator.services.mozilla.com/D86750
This should help catch and/or prevent any cases where we're creating a new
subframe at an unfortunate time during `BrowsingContext` or `WindowContext`
teardown.
Differential Revision: https://phabricator.services.mozilla.com/D85896
`ReadyToExecuteParserBlockingScripts` was walking the ancestor chain but
would stop if it hit an OOP ancestor. With this change we walk the
`WindowContext` tree instead, so that we may skip over OOP ancestors
and continue checking all in process ancestors.
Differential Revision: https://phabricator.services.mozilla.com/D86436
Creating more than 2 nested iframes is not allowed and is now enforced for
about:blank loads because they now take place via DocumentChannel.
Differential Revision: https://phabricator.services.mozilla.com/D85084
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 changes the set of types which can be passed as the second argument to
do_QueryActor to ones which can be unambiguously converted to a JSActorManager,
and combines nsCOMPtr_helper implementations.
Differential Revision: https://phabricator.services.mozilla.com/D84067