In the case we click a link from inside the frame, we don't want to
check for activation from the parent window but ourselves.
It feels like using the sourceWindowContext for these checks is always
the right thing to do, but it's not always possible if we set the
location.href from an out-of-process parent. In this case, we fall back
to consuming user activation on the iframe itself. This is tested in
browbrowser_protocol_ask_dialog.js when run with fission enabled.
We could consider making the user activation stuff more
multiprocess-friendly, but it's not clear to me it's worth it for this
particular edge case.
Differential Revision: https://phabricator.services.mozilla.com/D100578
In the case we click a link from inside the frame, we don't want to
check for activation from the parent window but ourselves.
It feels like using the sourceWindowContext for these checks is always
the right thing to do, but it's not always possible if we set the
location.href from an out-of-process parent. In this case, we fall back
to consuming user activation on the iframe itself. This is tested in
browbrowser_protocol_ask_dialog.js when run with fission enabled.
We could consider making the user activation stuff more
multiprocess-friendly, but it's not clear to me it's worth it for this
particular edge case.
Differential Revision: https://phabricator.services.mozilla.com/D100578
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
Per spec, whenever a "beforeunload" event handler which would affect a
`location.reload()` call exists, it must be called before the `reload()` call
returns. If a handler requests to block the navigation and we choose to
display a confirmation prompt, that must also be displayed before the call
returns.
With session history in parent, though, that currently does not happen,
because `location.reload()` triggers an async IPC call to the parent process,
and only attempts the actual reload (and thus beforeunload dispatch and
prompting) once it returns, which is too late to affect the caller.
This patch changes the handling in this case to manually perform permit unload
checks before taking an async code path. This still leaves the opportunity for
session history handlers in the parent to cancel the load asynchronously, but
that doesn't violate any spec-defined behavior.
Differential Revision: https://phabricator.services.mozilla.com/D94354
I think there could be still other issues with persist handling (or at least it could be simplified),
but this should be pretty much the minimal patch to fix the issue when
about:newtab url is changed to about:blank (without a redirect, but magical about: handling).
So we need to check persisted handling later than currently.
I'd prefer to land something like this first and then consider if there are better ways to handle
both about: url changes and proper redirects.
Depends on D93899
Differential Revision: https://phabricator.services.mozilla.com/D98871
And have it mirror in the parent process more automatically.
The docShellIsActive setter in the browser-custom-element side needs to
be there rather than in the usual DidSet() calls because the
AsyncTabSwitcher code relies on getting an exact amount of notifications
as response to that specific setter. Not pretty, but...
BrowserChild no longer sets IsActive() on the docshell itself for OOP
iframes. This fixes bug 1679521. PresShell activeness is used to
throttle rAF as well, which handles OOP iframes nicely as well.
Differential Revision: https://phabricator.services.mozilla.com/D96072
Only for top windows because for nested iframes they could get around
this without being noticed by reloading themselves which is not great.
Differential Revision: https://phabricator.services.mozilla.com/D98775
There are two issues in our current setup
1) Input events which are occurring in the same tab are going to be lost
because sync XHR. We have event handling suppression for synx XHR, so input
events are going to be discarded.
2) Input events that are happening in another tab (same process as the
synx XHR tab) are not going to be delayed. This is not correct since
sync XHR should block the Javascript execution.
This patches fixes the above cases for when both TaskController and e10s are
enabled by suspending the InputTaskManager during sync XHR, which
delays the input event handling and keeps the events around.
Differential Revision: https://phabricator.services.mozilla.com/D90780
I think this allows us to remove TryUsePopupOpeningToken (which is a similar
concept to consuming user activation), and also the ad-hoc <iframe> timing
thing we have from bug 1514547, which should be covered by the user activation
timeout.
Depends on D97640
Differential Revision: https://phabricator.services.mozilla.com/D98020
When re-enabling the test case blocked by bug 1670933 it became apparent that we were not allowing
session history entries to be marked with user interaction when the SH entry was created by navigation
through a sub-frame. The code that we had for this only covered updating SH entries after pushState etc.,
not adding new entries for document loads.
When SH lives in the child this is easier to manage in nsDocShell, but with Fission it probably makes sense
to move this code to the parent.
Differential Revision: https://phabricator.services.mozilla.com/D97421
This change removes docshell's `mTouchEventsOverride` and replaces it
with a new `BrowsingContext` field `TouchEventsOverrideInternal`.
All uses of the old field have been replaced and an override should
now work under fission when there are cross-origin descendent frames.
Differential Revision: https://phabricator.services.mozilla.com/D96414
Make it a synced field on the top browsing context. This handling the
propagation right and is much simpler.
This should fix cases where we don't look at the top level docshell to
figure out if we should suspend media.
Differential Revision: https://phabricator.services.mozilla.com/D94878
sizemode/displaymode media queries only affect a given browsing context
tree so there's no need to propagate the change to images in that case.
Differential Revision: https://phabricator.services.mozilla.com/D94422
