1973014 - Clicking on a link, etc. and loading a new page or menu is displayed as a click and that new page or menu opens (Example: YouTube video quality menu)

Status: VERIFIED FIXED

(Core :: DOM: Events, defect)

Description

[Claudiu]

Attachment: mobizen_20250619_130733.mp4

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:141.0) Gecko/20100101 Firefox/141.0

Steps to reproduce:

In defense of the quality selector on YouTube, the font remains bold on 720p quality. For example on this link: https://m.youtube.com/watch?v=1FwFuNfBX8Q&pp=0gcJCfwAo7VqN5tD

Actual results:

When you click on the quality of a video, a quality option, for example 720p, remains highlighted.

Expected results:

Font not displayed when pressing the quality settingFont should not be displayed when pressing the quality setting.

Comment 1

[Claudiu]

Attachment: mobizen_20250619_234235.mp4

It happens, for example, on the site: https://addons.mozilla.org/en-US/android/
It seems that the touch remains on the page where we click on a link.

Comment 2

[Claudiu]

(In reply to eclaudiu64 from comment #1)

Created attachment 9495872 [details]
mobizen_20250619_234235.mp4

It happens, for example, on the site: https://addons.mozilla.org/en-US/android/
It seems that the touch remains on the page where we click on a link.

I placed the link to recommended extensions in the middle of the site: See more recommended extensions and you can see that the touch remains on the next page, in my case, on the SingleFile extension.

Comment 3

[Chris Peterson [:cpeterson]]

Sorry, I'm not sure from the description what unexpected behavior the videos are showing. Is the problem with the menu font or the touch event intended for the menu instead triggering a click on the page behind the menu?

Comment 4

[Claudiu]

Clicking on a link, etc. and loading a new page or menu, is displayed as a click and that new page or menu opens, as can also be seen from the attached video capture.

Comment 5

[BugBot [:suhaib / :marco]]

The severity field is not set for this bug.
:boek, could you have a look please?

For more information, please visit BugBot documentation.

Comment 6

[Claudiu]

This error has already reached the Beta, possibly also the official version.

Comment 7

[Jeff Boek [:boek]]

Is this a recent regression?

Comment 8

[Claudiu]

(In reply to Jeff Boek [:boek] from comment #7)

Is this a recent regression?

Yes, it is from previous version 142 Nightly.

Comment 9

[Claudiu]

It is now reproducible in the official version 141.

Comment 10

[Claudiu]

Can you take a look here for a moment?

Comment 11

[Cathy Lu [:calu]]

This is only reproducible on Fenix, so not specifically a GeckoView issue. On GeckoView Example, the touch does not remain on the next page.
I'm not familiar with the code here, maybe Core Panning and Zooming can take a look? If not, feel free to change it back to Android General.

Comment 12

[Botond Ballo [:botond]]

To summarize my understanding of what the problem is: on Youtube, after opening the Settings menu and tapping "Quality", which opens another menu, the menu item at the location where you tapped on "Quality" in the old menu (e.g. "720p") is already highlighted in the new menu, even though you haven't tapped on the new menu yet.

(I'm not sure what the problem in the video from comment 1 on the addons.mozilla.org site is.)

This is a regression, and I am able to reproduce it in both Fenix and GeckoView Example. I used mozregression with GeckoView Example to find the following regression window:

https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=236f8bd740a391921bdbac5ecd5540d81d2c3eb4&tochange=b76ffb025765401511c2552e4ecdc1d4c3dbfdaf

In that window, bug 1633450 looks like the most likely suspect.

I see that the patches for bug 1633450 flip the default value of the pref layout.reflow.synthMouseMove. I tried turning this pref off in a build that reproduces the bug, and that indeed fixed the bug, thereby confirming bug 1633450 as the regressor.

==> Marking as a regression from bug 1633450

Comment 13

[Botond Ballo [:botond]]

(Moving to the component of the regressing bug.)

Comment 14

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 1633450

:masayuki, since you are the author of the regressor, bug 1633450, could you take a look?

For more information, please visit BugBot documentation.

Comment 15

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

Well, I don't reproduce this bug when I tap the "Quality" menu item with usual tap speed, but I reproduce it when I delay releasing the touch. When I try to do the same thing on Chrome, Chrome opens the context menu if I delay. So, I cannot compare the behavior from the reported case.

We started synthesizing eMouseMove for the last mouse location even if the last mouse location was specified by touch. So, if we stop dispatching that when the last mouse location was set by a touch like we're doing that for synthesized ePointerMove, we would "fix" this bug.

Comment 16

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

Hmm, maybe I'm wrong and I forgot something important change about the synthesized eMouseMove because scrolling the page in a simple testcase does preserve the :hover'ed element instead of applying to an element scrolled in to the last tapped position.

Comment 17

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

I think that this is the simplest testcase. When I tap quickly (leaving the finger quickly), the new items do not have :hover state. However, when I tap slowly, one of the new items has :hover state (highlighted as lightpink). According to the DOM events, the DOM events are synthesized as the same in the both cases. So, I'm still not sure what caused this difference.

Comment 18

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

We try to clear the last mouse pointer position at dispatching ePointerUp. However, the compatibility mouse events are fired after pointer events and touch events. Therefore, we store the mouse location after the pointer is inactivated due to non-stationally device.

Chrome sets :hover state when I long-press on an element, so, perhaps, we need to keep setting the :hover state with the compatibility mouse events, but I guess we should unset :hover state at eMouseUp if the device does not support hover state.

Anyway, we need to write some WPT to check the Chrome's behavior.

Comment 19

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

Let's try to stop synthesizing mouse move if the last one is caused by a touch.
https://treeherder.mozilla.org/jobs?repo=try&revision=b88662378e9db90e8f9069793e98a762e624ca51

However, I guess this will break something.

Comment 20

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

Attachment: Bug 1973014 - Stop synthesize mouse move events if the last mouse location is provided by pointing device which does not support hover state r=smaug!,#dom-core

A single tap or a long press may cause compatibility mouse events,
mousemove, mousedown, mouseup, then, click unless the target
is changed during the sequence. Currently, we synthesize a mouse move
event after a layout change or a scroll to dispatch mouse boundary
events and update the :hover state. However, if the last mouse event
is caused by a touch which does not support :hover state, it's odd
to treat the new target as hovered.

This patch prevents the synthesized mouse moves if the last mouse event
is caused by a pointing device which does not support hover state unless
the button state is active (e.g., the layout change at mousedown of
a single tap should cause mouse boundary events before the following
mouseup).

I think that the compatibility mouseup event should reset the
:hover state and dispatch mouse boundary events like pointerup.
However, Chrome does not do that. Therefore, we should align the
behavior to Chrome for the compatibility.

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8461aba08464
https://hg.mozilla.org/integration/autoland/rev/aec4650474d0
Stop synthesize mouse move events if the last mouse location is provided by pointing device which does not support hover state r=smaug,dom-core-reviewers

Comment 22

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/61037 for changes under testing/web-platform/tests

Comment 23

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/aec4650474d0

Comment 24

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot

Comment 25

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

If you still see the bug itself or similar bug, please file a new bug instead of reopening this because my patch fixes a symptom at least the testcase. So, we really change a behavior in this bug so that the regression of that should be managed with this bug and bugs which would fix the other symptoms shouldn't be mixed in the regression management.

Comment 26

[BugBot [:suhaib / :marco]]

The patch landed in nightly and beta is affected.
:masayuki, is this bug important enough to require an uplift?

• If yes, please nominate the patch for beta approval.
  • See https://wiki.mozilla.org/Release_Management/Requesting_an_Uplift for documentation on how to request an uplift.
• If no, please set status-firefox153 to wontfix.

For more information, please visit BugBot documentation.

Comment 27

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

This changes a major behavior after a single tap and a long tap. So, it may be risky to uplift.

However, this fixes a bug in a major app, YouTube, at least. So, it's okay to uplift this if this is important for the market.

Comment 28

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

FYI: I verified this fixed the issue on YouTube's menu.