Closed Bug 1685441 Opened 4 years ago Closed 3 years ago

Event retargeting causes click event to target wrong element

Categories

(Core :: Panning and Zooming, defect, P3)

Product:
Core
Component:
Panning and Zooming
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME
Tracking Flags:
Tracking Status
firefox-esr78 --- wontfix
firefox84 --- wontfix
firefox85 --- wontfix
firefox86 --- wontfix
firefox87 --- wontfix

People

(Reporter: botond, Unassigned)

References

(Blocks 1 open bug, Regression,
URL
)

Details

(Keywords: regression)

STR

  1. Load https://codepen.io/ksy36/pen/jOMKBwa in Firefox for Android.
  2. Tap on the icon.

Expected results

The page displays "icon" (resulting from the click event targeting the icon).

Actual results

The page displays "wrongElement" (resulting from the click event targeting the element with the red box).

The issue is related to event retargeting and can be worked around by setting ui.mouse.radius.enabled=false.

Thanks Ksenia for the reduced testcase!

The intention of event retargeting is to re-target an event from a target which does not handle it, to a nearby target which does.

In this case, I guess we consider the icon to not handle click events because it is not the icon which has the click event handler, but the document.

I can also reproduce the issue in RDM with ui.mouse.radius.enabled=true (which is not the default on desktop) + touch simulation enabled.

This would have been most recently regressed by the re-enablement of mouse event retargeting in bug 1618532.

Previously, the feature was disabled for a while (since bug 1247095) but its disablement was causing a different set of problems (small elements being hard to hit).

Regressed by: 1618532

(In reply to Botond Ballo [:botond] from comment #1)

In this case, I guess we consider the icon to not handle click events because it is not the icon which has the click event handler, but the document.

We do check for clickable ancestors of the initial target, but we stop the search before considering the <body> or <html> elements, or the document itself. This is because these elements tend to have listeners for the relevant event types (such as mousedown or click) fairly frequently, and disabling retargeting for the entire document makes retargeting a much less useful feature. This behaviour has been in place since bug 901117.

Regressed by: 901117
Has Regression Range: --- → yes

Unfortunately, I don't think there is a good general solution to this problem. We can't analyze the JS code of event handlers on the document to figure out the specific sub-elements they are interested in (such as the icon in this case), and there is a fundamental tradeoff between disabling retargeting on the entire document if it has a click event listener vs. making it reasonably easy to target small / narrow descendants of the document (such as the red box in this case) which have their own event handlers.

In previous cases where we've run into this sort of issue, we've worked around it by adding various heuristics to the event retargeting code to figure out what is intended to be clickable (for example, in bug 1632941 we started to consider elements with the cursor: pointer style clickable, and in bug 1666792 we made it so that we don't re-target events to an element with a different z-index).

It's possible that we could devise a heuristic by which we treat the icon as clickable in this case as well (though we'd have to look at the original website, which is https://www.chattamil.com/chat.php, rather than the reduced testcase for that).

Beyond that, one thing we can do to alleviate problems like this, is to suggest to website authors that they register click and similar event handlers on the more specific elements of interest (such as the icon in this case) rather than the document. In some cases this choice might be made at the level of a framework, in which case a change could solve similar issues on a variety of sites using the framework.

URL: https://www.chattamil.com/chat.php
Severity: -- → S3
Priority: -- → P3
Blocks: apz-retarget

I happened to notice Android's MotionEvent provides the information what caused the event, such as by a finger or style or mouse. (We've used it, for example here).

And looks like in cases of finger touches Chrome does a tweak (there may be more, I've just found one) that enlarging hit_rect_size towards top-left direction, I don't know what the original hit_rect_size is, I don't know whether we have already similar tweaks or not, so just FYI.

Thanks for having a look!

(In reply to Hiroyuki Ikezoe (:hiro) from comment #6)

And looks like in cases of finger touches Chrome does a tweak (there may be more, I've just found one) that enlarging hit_rect_size towards top-left direction, I don't know what the original hit_rect_size is, I don't know whether we have already similar tweaks or not, so just FYI.

It looks like they are expanding the hit-test point to a rect centered on that point. This is similar to what we do.

I think this bug is WFM now. On the original URL (https://www.chattamil.com/chat.php) the group icon in question now has a click event listener, and so gets targeted fine. I verified on both Fenix (release) and in the desktop setup from comment 2.

Please free to reopen if you're still seeing this issue.

Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.