This patch doesn't change behavior; it's just switching us between two
functions that do the same thing. (One is literally a trivial wrapper for the
other.)
We're using the new "InProcess" version of this API as a way of annotating
callsites that have been vetted as behaving properly in out-of-process iframes.
This patch fixes two callsites:
- The first callsite is an assertion whose condition becomes slightly stricter
but should still be valid, in a scenario where we are at an oop-iframe
boundary.
- The second is in IsFrameScrolledOutOfView(), which is part of an API that we
use to optimize away animations if we can tell they're in an invisible
subtree (see calls to IsScrolledOutOfView() in KeyframeEffect.cpp). If we
run up against an out-of-process iframe boundary when calling
GetCrossDocParentFrame() here, we'll still be OK -- we should still be able
to figure out whether the animation is invisible, via our call to
nsLayoutUtils::FrameIsScrolledOutOfViewInCrossProcess() a few lines further
down. (Also: worst-case, we'll just run the animation even though it's not
visible; so there's no loss of correctness.)
Differential Revision: https://phabricator.services.mozilla.com/D108878
This patch doesn't change behavior; it's just switching us between two
functions that do the same thing. (One is literally a trivial wrapper for the
other.)
We're using the new "InProcess" version of this API as a way of annotating
callsites that have been vetted as behaving properly in out-of-process iframes.
This patch is focusing on some callsites where we've got a frame that needs a
repaint, and we're propagate that information up its ancestor chain. It's OK
for these notifications to stop when we hit the edge of of an out-of-process
iframe, because painting/compositing at that granularity is handled separately.
Differential Revision: https://phabricator.services.mozilla.com/D108877
We assumed parent content wasn't null because we've already checked that there is a parent table accessible, suggesting there's also parent content.
However, if the tr is at the top level of a shadow root (but the table is not), parent content will be null, causing a crash.
Before the fix for bug 1686123, this was fine because the frame for a shadow root is null and we didn't continue for a null frame.
Now that we do continue for a null frame, we must null check parent content.
Differential Revision: https://phabricator.services.mozilla.com/D108777
This is to fix intermittent failure on all browser toolbox tests.
It looks like these patches make toolbox.destroy shuts down connection faster
and lead to evaluateJSAsync request still be pending while the connection is closed
and actors and fronts are destroyed.
Differential Revision: https://phabricator.services.mozilla.com/D108630
Still use a shouldCloseClient flag, but instead of closing the client from the target's destruction,
from which we should ignore cross process target switching,
we now close it from the descriptor destruction.
Descriptor destruction should only happen when the toolbox is meant to be closed.
Differential Revision: https://phabricator.services.mozilla.com/D106835
Close method may be called by the transport on close.
This was highlighted by browser_target_from_url.js
Surprisingly devtools/shared/tests/xpcshell/test_debugger_client.js
tries quite hard to cover such issue, but we seem to get yet another type of reentrancy.
This probably depends on WebSocketTransport, which is a bit hard to get covered.
No test seems to be spawning a WebSocket DevToolsServer...
Differential Revision: https://phabricator.services.mozilla.com/D107988
This aligns Mac's focus model with other platforms. Matches Chromium, but not
Safari.
Reasons why I think it's worth making this change:
* Consistency with all other platforms.
* Makes the :focus-visible implementation more useful.
* Fixes focus navigation after e.g. clicking a button.
* Shouldn't cause a lot more outlines to show up (at least not by default).
An example of the second point:
data:text/html,<button onclick="this.nextElementSibling.focus()">Click</button><button>Imagine I'm a dialog close button or something</button>
In non-macOS platforms, we won't show an outline for the button in that case,
which matches the developer expectations (links below). We don't show the
outline because the focus comes from an element that has been focused by mouse
(and thus didn't show an outline). But on macOS that doesn't work, because the
button is not focused.
For completeness, the actual heuristics for :focus-visible may change a bit as
a result of the discussions in:
* https://github.com/w3c/csswg-drafts/issues/5885
* https://github.com/web-platform-tests/wpt/pull/27806
But it's not clear to me how to best define this so it works on the macOS focus
model.
An example of the third point:
data:text/html,<input type=text><input type=submit><input type=text>
On Safari and Chrome (and Firefox on non-macOS platforms), clicking the button,
then pressing tab, goes to the input on the right. In Firefox on macOS it
doesn't because the button doesn't gain focus nor is selectable.
Differential Revision: https://phabricator.services.mozilla.com/D108808
This change is just cleanup and have no behavioral difference, given that
SetThemeRegion only does anything for eWindowType_popups, which never have a
skeleton UI.
Depends on D108849
Differential Revision: https://phabricator.services.mozilla.com/D108850
We were skipping the initial ResizeDirectManipulationViewport call when the
skeleton UI showed a maximized window, because it pseudo-ignores the first
Move/Resize in order to not break the maximization. There's no reason
ResizeDirectManipulationViewport should have been in the else clause - it just
wasn't properly considered.
Differential Revision: https://phabricator.services.mozilla.com/D108849
Taking a similar approach to the regular Reftest actors, we recursively call flush rendering using js window actors in all remote frames.
The main difference with the regular Reftest actor is that the top frame's flushRendering is still performed as part of the reftestWait call.
The reason for that is that we perform 2 flushRendering in case there is a "reftest-wait" classname, which is easier if we keep it outside of the recursive call.
Differential Revision: https://phabricator.services.mozilla.com/D108420
We can either get here via touch events interpreted as a double tap, or a double tap event sent from the os. The former will have a touch block, the latter will have no input block associated with it.
The crash shows it's possible to get here with another type of current input block.
The other option would be to ignore the double tap if we get here and there is a current input block that is not touch. Not sure if that is better or not.
Differential Revision: https://phabricator.services.mozilla.com/D108716
The widget is only added if screenshots are enabled (similar behavior to the fxa
toolbar button).
Button must take into account onLocationChange due to the fact that screenshots
extension is not available on about pages.
Adds a test for the disabled state, with more screenshot tests intended in the future
Differential Revision: https://phabricator.services.mozilla.com/D107727
Analogous to the draw compositor. This is needed for Wayland and
potentially Android.
It maybe doesn't not yet cover all cases, howewer it is enough to allow
the example compositor to work correctly.
Differential Revision: https://phabricator.services.mozilla.com/D108610
Markus Stange
Andrei Cristian Petcu
Ting-Yu Lin
Daniel Holbert
Cosmin Sabou
James Teh
Lee Salzman
Alexandre Poirot
Henry Vincent
Dave Hunt
Emilio Cobos Álvarez
Glenn Watson
Ed Lee
sotaro
Timothy Nikkel
Doug Thayer
Tim Nguyen
Tom Schuster
Emma Malysz
Julian Descottes
Bogdan Tara
Mike Kaply
Alex Ionescu
Yury Delendik
Robert Mader
Jonathan Kew
Joel Maher
Andrew Osmond
Mark Banner