1983191 - When you tap right side space of the link list, a link is clicked instead of the rightmost clickable `<span>`

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

STR

1. Load https://jsfiddle.net/d_toybox/95bcdxm4/1/show on Android or on Desktop
2. If you load the page on Desktop, press Ctrl + Shift + M to enter the RDM mode of the DevTools, enable "Touch simulations" of that and set ui.mouse.radius.enabled and ui.touch.radius.enabled to true in about:config
3. Tap right space of the red box

Actual Result

Alert shows "A link whose text is ジャンル[23] is clicked".

Expected Result

The alert should show "<span> is clicked as expected".

Note

I found this issue in some EC site in Japan. The red box is used to extend the link list to show all items. I.e., when I try to open all links to check them, accidentally I was navigated to another page. So, this could cause dataloss if the session management in the server side does not work with "Back" navigation or inputted data into the page.

The source is here: https://jsfiddle.net/d_toybox/95bcdxm4/1/

I filed this as a bug of Layout because this is a bug in GetClosest().

Comment 1

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Log of "event.retarget" with some additional info:

eMouseDown:

[Child 86000: Main Thread]: D/event.retarget Expanded point to target rect (x=10270, y=0, w=3600, h=2090)
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44c57410 (i.span.dl.body.html.#document @ 0000012A44E03F70) with border box (x=11040, y=780, w=840, h=840)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44c57410 (i.span.dl.body.html.#document @ 0000012A44E03F70) is the new best (190.000000)
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44c57320 (#text._moz_generated_content_before.span.dl.body.html.#document @ 0000012A44E09580) with border box (x=10251, y=707, w=549, h=986)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44c57320 (#text._moz_generated_content_before.span.dl.body.html.#document @ 0000012A44E09580) was not the new best (190.000000 vs 1270.000000)
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44c57258 (_moz_generated_content_before.span.dl.body.html.#document @ 0000012A44E0F5E0) with border box (x=10251, y=720, w=549, h=960)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44c57258 (_moz_generated_content_before.span.dl.body.html.#document @ 0000012A44E0F5E0) had empty hit region
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44c57110 (span.dl.body.html.#document @ 0000012A44E03EE0) with border box (x=10251, y=720, w=1629, h=960)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44c57110 (span.dl.body.html.#document @ 0000012A44E03EE0) was ancestor for bestTarget 12a44c57410
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44cedb98 (#text.a[href=""].span.dd.dl.body.html.#document @ 0000012A44E08B80) with border box (x=9533, y=647, w=3006, h=986)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44cedb98 (#text.a[href=""].span.dd.dl.body.html.#document @ 0000012A44E08B80) is the new best (0.000000)
<snip>
[Child 86000: Main Thread]: D/event.retarget Final target is 12a44cedb98
[Child 86000: Main Thread]: D/event.retarget Found initial target 12a44cecca8 for event class eMouseEventClass message eMouseDown point (12070,1190) relative to root frame {0000012A44CEC020, layout}

eMouseUp:

[Child 86000: Main Thread]: D/event.retarget Expanded point to target rect (x=10270, y=0, w=3600, h=2090)
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44c57410 (i.span.dl.body.html.#document @ 0000012A44E03F70) with border box (x=11040, y=780, w=840, h=840)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44c57410 (i.span.dl.body.html.#document @ 0000012A44E03F70) is the new best (190.000000)
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44c57320 (#text._moz_generated_content_before.span.dl.body.html.#document @ 0000012A44E09580) with border box (x=10251, y=707, w=549, h=986)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44c57320 (#text._moz_generated_content_before.span.dl.body.html.#document @ 0000012A44E09580) was not the new best (190.000000 vs 1270.000000)
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44c57258 (_moz_generated_content_before.span.dl.body.html.#document @ 0000012A44E0F5E0) with border box (x=10251, y=720, w=549, h=960)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44c57258 (_moz_generated_content_before.span.dl.body.html.#document @ 0000012A44E0F5E0) had empty hit region
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44c57110 (span.dl.body.html.#document @ 0000012A44E03EE0) with border box (x=10251, y=720, w=1629, h=960)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44c57110 (span.dl.body.html.#document @ 0000012A44E03EE0) was ancestor for bestTarget 12a44c57410
[Child 86000: Main Thread]: D/event.retarget Checking candidate 12a44cedb98 (#text.a[href=""].span.dd.dl.body.html.#document @ 0000012A44E08B80) with border box (x=9533, y=647, w=3006, h=986)
[Child 86000: Main Thread]: D/event.retarget   candidate 12a44cedb98 (#text.a[href=""].span.dd.dl.body.html.#document @ 0000012A44E08B80) is the new best (0.000000)
<snip>
[Child 86000: Main Thread]: D/event.retarget Final target is 12a44cedb98
[Child 86000: Main Thread]: D/event.retarget Found initial target 12a44cecca8 for event class eMouseEventClass message eMouseUp point (12070,1190) relative to root frame {0000012A44CEC020, layout}

Comment 2

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

So, the distance to the link adjusted to click 0.0, but the one to the <span> is considred as 190.0. I.e., treated as clicked in the link?

Comment 3

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Ah, okay, so, I think the partial overlap of the <span> over the links is not correctly handled. Well, if we could consider the adjusted clicked position in the frame rect and if the point is overlapped by a non-descendant frame, we should skip the candidate frame.

Comment 4

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Perhaps, I succeeded to fix this bug.
https://treeherder.mozilla.org/jobs?repo=try&landoCommitID=147918

Comment 5

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Attachment: Bug 1983191 - Make `PositionedEventTargeting` use the nearest point in the frame region r=smaug!,#dom-core,#layout-reviewers!

The found frame may be overlapped by another frame and the another frame
may not be descendant of the frame. Then, web app want to hide the
frame to make the overlapping element should handle the click/tap.
Therefore, if clicking/tapping point is on the overlapping element,
the overlapped element should not be so sensitive.

This patch computes the nearest point in the region from the event
point. Then, check whether the point is covered by another frame which
is not a descendant. If it's covered, we start ignoring the frame.

Then, this patch computes the distance between the nearest point and
the event point. This distance should be same as the value which we have
computed.

Comment 6

[Timothy Nikkel (:tnikkel)]

I find that I run into a lot of issues with this code producing less then desirable results, see bug 1687382 and linked bugs from there, so I am happy to see that you are trying to improve it, thanks!

Comment 7

[Emilio Cobos Álvarez [:emilio]]

Unless I'm missing something the root cause here is that GetClosest assumes the whole border box of the element is hittable, which is just not true (it's clipped by the overflow: hidden in this testcase).

Fixing that rather than papering over it with a separate hit testing seems preferable, and we should be able to reuse some of the IntersectionObserver code for that afaict? It's doing very similar stuff.

Comment 8

[Sky Schubert [:skyschub][Vacation, back 2026-08-24]]

Unsetting the WebCompat tracking flags. We don't have a "real site" to triage this on based on the data in this bug. Masayuki-san, I did notice

I found this issue in some EC site in Japan.

in comment 0. If this is affecting a real site, please file a Site Report for that case and mark it as being blocked by this bug - so we can properly triage that. :)

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Okay, I filed an ebook site which I usually see this issue. I saw similar issues in some other sites, but a site which I remember has changed the design, so the UI has gone from another site. I don't remember the others which I saw this.
https://github.com/webcompat/web-bugs/issues/174026

Comment 10

[Brian Birtles (:birtles)]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #9)

Okay, I filed an ebook site which I usually see this issue. I saw similar issues in some other sites, but a site which I remember has changed the design, so the UI has gone from another site. I don't remember the others which I saw this.
https://github.com/webcompat/web-bugs/issues/174026

Just for reference, for people familiar with Bugzilla, I think we prefer filing bugs in Bugzilla at the moment since moderation in the webcompat repository can take quite a while.

Comment 11

[Sky Schubert [:skyschub][Vacation, back 2026-08-24]]

I think we prefer filing bugs in Bugzilla

++, our triage folks will move it to Bugzilla anyway :) But we never communicated that to everyone, I think - Sorry for that.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/884f38e5c486
https://hg.mozilla.org/integration/autoland/rev/75211d623a16
Make `PositionedEventTargeting` use the nearest point in the frame region r=smaug,dom-core,layout-reviewers,emilio

Comment 13

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/684357a96b20
https://hg.mozilla.org/integration/autoland/rev/62a7c5138e60
Revert "Bug 1983191 - Make `PositionedEventTargeting` use the nearest point in the frame region r=smaug,dom-core,layout-reviewers,emilio" for causing failures on test_event_target_radius.html

Comment 14

[Narcis Beleuzu [:NarcisB]]

Backed out for causing failures on test_event_target_radius.html

Backout link: https://hg-edge.mozilla.org/integration/autoland/rev/62a7c5138e60ae1860018728d80b0c188bc5a845
Log link: https://treeherder.mozilla.org/logviewer?job_id=526308689&repo=autoland&task=f6sr5_VtTaWR9gFwUkRtJQ.0&lineNumber=3383

Comment 15

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, that's odd, the test passes in mochitest-plain which should run with fission.

The iframe's origin is "example.com". I'm not sure whether this is isolated in the isolateHighValue mode because it depends on some permissions which may be changed by a preceding test... but if the <iframe> is isolated, the behavior should be same as running as mochitest-plain. So, I guess the <iframe> is not isolated. If so, making the test run forcibly without fission may fail too. I'll try.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Oh, but if it's not isolated, it should fail due to bug 1890522??
https://searchfox.org/firefox-main/rev/3c23ce1368431d49bae08e8e211f7f2bf4e4829d/layout/base/tests/test_event_target_radius.html#499-501

I'm really confused.

Comment 17

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Hmm, invalid padding value... I need to check whether test actually check the expected situation.

Comment 18

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Okay, it detects a regression in in-process <iframe> if it's scaled by an ancestor. I guess the usage of DOMInterectionObserver is wrong.

Comment 19

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #18)

Okay, it detects a regression in in-process <iframe> if it's scaled by an ancestor. I guess the usage of DOMInterectionObserver is wrong.

It seems that this is another bug. Even if I confirmed that it works within <iframe> scaled by ancestor, the test keeps failing. So, I think the test itself has a bug.

Comment 20

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Filed bug 1987833 for a bug in in-process <iframe> which is scaled in the parent document. I won't fix it in this bug because it does not related to the actual web site which I find this bug.

Comment 21

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to Masayuki Nakano [:masayuki] (he/him)(JST, +0900) from comment #20)

Filed bug 1987833 for a bug in in-process <iframe> which is scaled in the parent document. I won't fix it in this bug because it does not related to the actual web site which I find this bug.

Hmm, but it seems that the rounding issue caused the failure on Windows.

Comment 22

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Okay, I'll land the patches with changing some tests because they are just broken after the soft code freeze. Changing the desktop scale can make some tests fail easy. All of the breakable tests are testing click or tap at midpoint of 2 elements. E.g., in some conditions, it fails to click/tab the exact midpoint of the 2 elements due to rounding issue or something.

Comment 23

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

And such tests are not important because it's impossible that the users intentionally click/tap exactly midpoint of 2 elements. So, they just check the intention/logic of PositoinedEventTargeting.

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/ee7ef731c975
https://hg.mozilla.org/integration/autoland/rev/7eb1546c8e86
Make `PositionedEventTargeting` use the nearest point in the frame region r=smaug,dom-core,layout-reviewers,emilio

Comment 25

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/7eb1546c8e86