Commit automatically generated through clang-tidy's
performance-use-std-move new pass.
- nsCOMPtr benefits from being moved
- Maybe type has a custom move-assign operator
- nsAutoCString benefits from being moved
- nsRegion benefits from being moved
Differential Revision: https://phabricator.services.mozilla.com/D285677
On Windows, we do not spoof touch-related inputs anymore, and we
pretend touch is always available.
There is no reason not to do the same on Linux, even though the code to
report the number of maxTouchPoints is not implemented there.
Differential Revision: https://phabricator.services.mozilla.com/D267266
This reverts commit 35055c39b0.
Revert "Bug 1991701 - Re-enable touch on Linux with RFP and remove RFPTarget::PointerId. r=tjr,layout-reviewers,emilio"
This reverts commit 00f1baf7d5.
On Windows, we do not spoof touch-related inputs anymore, and we
pretend touch is always available.
There is no reason not to do the same on Linux, even though the code to
report the number of maxTouchPoints is not implemented there.
Differential Revision: https://phabricator.services.mozilla.com/D267266
In bug 1181763, we made the method retarget to inner element when
tapping/clicking around the inner element because there are nested
click event handlers in the reported case. This should be reasonable
if the inner element is in a clickable/touchable element which is
different from the clickable/touchable element at the event point since
it's hard to click/tap a small element and users usually don't click/tap
around the another element to click/tap the outer element which should
be bigger than the inner one.
However, in the reported case in bug 1978818, the click event handler
may check the event target strictly. Then, retargeting to an inner
element may block the user's intention. Therefore, we should not
retarget if and only if the user clicks/taps outer element and already
found nearest target is clickable/touchable by the same element at
the clicked/tapped position.
Differential Revision: https://phabricator.services.mozilla.com/D261848
The found frame may be covered by another frame. However, current
implementation may use the covered frame as the target if it's the
nearest frame from the click/touch point.
A frame is covered by another frame means that web apps try to prevent
the users to click/tap the frame. Therefore, current behavior may make
it possible to click/tap an element which is tried to hidden. Thus,
current behavior may be not expected by both the web app developers and
the users.
This patch uses a part of intersection observer to get clipped border
box of a candidate frame. So, if the frame is clipped by the
containers, the hidden region becomes not clickable/touchable.
NOTE: This backouts D67521 which is the patch for the test. If the
resolution is not 1.0, it's fine to skip the midpoint tests on Android
because it's tested on the desktop platforms within the decimal world.
Differential Revision: https://phabricator.services.mozilla.com/D261223
The found frame may be covered by another frame. However, current
implementation may use the covered frame as the target if it's the
nearest frame from the click/touch point.
A frame is covered by another frame means that web apps try to prevent
the users to click/tap the frame. Therefore, current behavior may make
it possible to click/tap an element which is tried to hidden. Thus,
current behavior may be not expected by both the web app developers and
the users.
This patch uses a part of intersection observer to get clipped border
box of a candidate frame. So, if the frame is clipped by the
containers, the hidden region becomes not clickable/touchable.
Differential Revision: https://phabricator.services.mozilla.com/D261223
Pointer Events now defines that click event target should be the captured target
which is the target of the source event [1] and `pointerdown` will start
implicit pointer capture with its target when nobody explicitly sets pointer
capture [2].
Once we will use the standardized behavior in bug 1885232, touch input device
users will become harder to click an element which does not have touch event
listeners because `touchstart` event target which is same as the `pointerdown`
event target is not retargeted and it becomes the following `click` event
target.
Therefore, single touch start around clickable element should be retargeted to
the element if there is no touchable element.
Differential Revision: https://phabricator.services.mozilla.com/D245686
We have more readable and faster versions (that just omit the namespace
arg).
Mostly done via sed, with a couple helpers to use the faster lookups
where possible.
Differential Revision: https://phabricator.services.mozilla.com/D181795
When using apz-retarget, hit test area is expanded. So if this area includes
previous line in <textarea>, we will select previous line. But when hit test
area is empty area of <textarea>, we should set caret to last character.
So I think that we should be disable apz-retarget if target is in <textarea>.
Differential Revision: https://phabricator.services.mozilla.com/D107441
Add a dom/base/rust crate called just "dom" where we can share these.
Most of the changes are automatic:
s/mozilla::EventStates/mozilla::dom::ElementState/
s/EventStates/ElementState/
s/NS_EVENT_STATE_/ElementState::/
s/NS_DOCUMENT_STATE_/DocumentState::/
And so on. This requires a new cbindgen version to avoid ugly casts for
large shifts.
Differential Revision: https://phabricator.services.mozilla.com/D148537
This is mostly edge-casey, but see bug 1757156 for an example where it's
causing some issues (granted, they could use `href="#"` or something
instead of an empty href).
It feels weird if a link looks like a link (because the CSS definition
of a link matches, which is "has an href") but then mostly doesn't
behave as a link.
We can't navigate anywhere if we don't have a valid URI but maybe JS
handles the relevant events as in bug 1757156.
Use the CSS definition (has href) since that's interoperable across
browsers. This should also make some stuff much faster (since checking
'is link' is now just a bit check instead of a virtual call).
(Awaiting try results, if no tests need adjustments then I need to write
some)
Differential Revision: https://phabricator.services.mozilla.com/D142107
Touches that land on a descendant of a clickable element should
not get retargeted to other nearby elements because the descendant
itself can react to those touch events.
Differential Revision: https://phabricator.services.mozilla.com/D102827
The audio/video controls element has touch listeners on the scrubber, which
steals events when we don't want it to. So let's ignore those listeners.
Ignoring system group listeners for the purposes of event retargeting seems
reasonable in the general case, because those listeners are coming from the
browser itself. If we're relying on the event retargeting to make those browser
elements easy to hit, then we should not be doing that and instead just make
them bigger.
Test coverage for this change is provided by the android-components tests that
failed in bug 1668112. The next patch re-enables touch event retargeting and
exercises this code in the context of those tests.
Depends on D92436
Differential Revision: https://phabricator.services.mozilla.com/D92437
And enable the assertion for the same-document case.
Without this patch, the assertion would fire in tests like
gfx/layers/apz/test/mochitest/test_group_zoom.html, where stuff like
MaybeHandleEventWithAccessibleCaret, which passes a non-root-frame down
here, and a target, which ends up violating the preconditions of
ClipToFrame, etc.
Enable the assertion for the same-document case, there are other
violations when fission is enabled in the cross-document case.
Differential Revision: https://phabricator.services.mozilla.com/D91966
Apparently a bunch of Stringify(nsRect) sites were getting converted to
Stringify(nsRegion(nsRect)) due to the the nsRegion implicit constructor, so
this updates those too.
Depends on D91524
Differential Revision: https://phabricator.services.mozilla.com/D91525
The existing heuristics in GetClickableAncestor have evolved over time to be
quite specific to mouse/click events, because those are the ones that we have
enabled by default. The heuristics we want for touch events are different and
should generally be very conservative, because we almost never want to retarget
the raw touch events. This patch introduces a new GetTouchableAncestor
function that implements this new conservative heuristic function and uses it
for determining the retargeting destination for touch events.
Differential Revision: https://phabricator.services.mozilla.com/D91027
There's a few early-return conditions where we don't need to do this computation
at all. So this patch just moves the computation to after the early-returns. No
functional changes intended.
Differential Revision: https://phabricator.services.mozilla.com/D91025
This is a weird conversion because the existing VarCache mirror prefs are in a
two static structs, one for touch prefs and one for the equivalent mouse prefs,
and we dynamically select the appropriate struct in `GetPrefsFor()`.
(But note that `ui.mouse.radius.reposition` and
`ui.mouse.radius.inputSource.touchOnly` do not have corresponding `touch`
prefs! For touch events they are always considered to be false.)
The commit make the following changes.
- It makes the prefs into static prefs.
- It moves the code in `GetPrefsFor()` into a constructor for
`EventRadiusPrefs`, and copies the pref values into a temporary object of
that type. Those copied values are then used by the subsequent code.
- It removes the two static `EventRadiusPrefs` structs.
- It renames some fields in `EventRadiusPrefs` to make them more closely match
the pref names.
Differential Revision: https://phabricator.services.mozilla.com/D79405
This removes the need for FrameForPointOptions::IsRelativeToLayoutViewport,
and makes sure each call site of these functions indicates whether the
input point/rect is in visual or layout coordinates.
Several call sites were passing in layout coordinates without setting the
IsRelativeToLayoutViewport flag, which this patch corrects.
Differential Revision: https://phabricator.services.mozilla.com/D71705
Sylvestre Ledru