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
I'm hoping this fixes (or at least helps with) this intermittent test failure
(an intermittent test-timeout).
Before this patch, the test did the following: it made a layout-impacting
restyle, and then it registered a reflow observer, and then it waited for the
previously-performed restyle to be flushed, which it then expects to cause a
reflow and trigger the reflow observer.
When the test times out and intermittently fails, it seems that the reflow
observer is successfully registered but never fires. I'm guessing that's
because the reflow is getting flushed eagerly for some reason, and happens
*before* the reflow observer is registered. We can avoid this problem by
holding off on the restyle until after the reflow observer has been registered;
that's the approach that this patch takes.
(Note that this reflow-observer API isn't web-exposed; it's an internal API that
we use to report reflows in our devtools.)
Differential Revision: https://phabricator.services.mozilla.com/D100517
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
Bug 1583109 introduced new function templates StringJoin and StringJoinAppend.
These are now used to replace several custom loops across the codebase that
implement string-joining algorithms to simplify the code.
Differential Revision: https://phabricator.services.mozilla.com/D98750
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
aLink might be null in the parent process, and even though it's only
null when getting URIs via IPC (which should never hit this code path in
a correct execution), we don't trust the child process so this is safer.
Differential Revision: https://phabricator.services.mozilla.com/D99703
When a user clicks a form, the password manager popups a warning when the
form is not in a secure context. However, there is an exception when
a form is in an iframe. When both the url of the iframe and the top-level
are both local ip addresses, we consider it is safe.
This patch adds isLocalIP to WindowContext and WindowGlobalActor.webidl
so password manager can identify whether the top-level url is a local ip
address under fission.
Differential Revision: https://phabricator.services.mozilla.com/D99041
Butkovits Atila
Micah Tigley
Kris Maglione
Alexis Beingessner
Olli Pettay
Razvan Maries
Sylvestre Ledru
Mihai Alexandru Michis
Nika Layzell
Noemi Erli
Emilio Cobos Álvarez
Narcis Beleuzu
Daniel Holbert
Andi-Bogdan Postelnicu
Jonathan Kew
Cosmin Sabou
Steve Fink
Yaron Tausky
Andreas Farre
Peter Van der Beken
Daisuke Akatsuka
Simon Giesecke
Masatoshi Kimura
Csoregi Natalia
Sean Feng
Dimi Lee