1919411 - <a> :hover state gets triggered atomically with the long-press context-menu on Firefox, vs. slightly before the long-press context-menu in Chrome

Status: RESOLVED FIXED

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

Description

[Daniel Holbert [:dholbert]]

STR:

1. In Firefox for Android, visit https://bugzilla.mozilla.org/attachment.cgi?id=9425357
2. Touch the "ANCHOR" element (either the text or anywhere in the black box, I don't think it matters), and immediately drag up/down to scroll the page. Release your finger.
3. If the anchor element got a colorful background, tap elsewhere (e.g. the "DIV") so that ANCHOR loses its background.
4. Repeat steps 2-3, waiting shorter/longer amounts between touching the screen and when you drag up/down.

ACTUAL RESULTS:
In Firefox, the anchor element only gains a background (a hover-state) when you've long-pressed it (without yet scrolling) for long enough to trigger a context-menu.

EXPECTED RESULTS:
In Chrome, the anchor element gains a background when you've long-pressed it (without yet scrolling) for a short amount of time, which is shorter than the time that it takes to trigger the context-menu.

This ends up meaning that it's possible to trigger the hover-state without triggering a context-menu (and without actually navigating to the link-target) in Chrome, but not in Firefox.

I'm not sure this area (:hover on Android) is well-specced, but it's perhaps worth considering whether Chrome's behavior here makes any sense and is worth aligning on for compat. We do have one webcompat site-report that was filed about this (bug 1907805) though it's not clear the use-case-that-works-in-Chrome-but-not-Firefox there (making :hover preview images appear by touching and scrolling) is particularly robust or by-design.

Comment 1

[Daniel Holbert [:dholbert]]

screencast showing Chrome first, then Firefox Nightly, on my Pixel 8 with Android 14:
https://drive.google.com/file/d/1jFjkkH7aWQZOBJpR4IBPHcb73oUWB2mb/view?usp=sharing

In Chrome, you can see that the anchor is typically treated as hovered after I've touched it without moving for a moment (maybe 100ms? not sure), and its context-menu doesn't appear if I then start scrolling.

In Firefox, the hover-state doesn't get activated until the context-menu appears.

Comment 2

[Sean Feng [:sefeng211]]

Given the webcompat bug has a S3 severity, I am marking this one as the same.

Comment 3

[Hsin-Yi Tsai (she/her)[:hsinyi]]

(In reply to Daniel Holbert [:dholbert] from comment #0)

STR:

1. In Firefox for Android, visit https://bugzilla.mozilla.org/attachment.cgi?id=9425357
2. Touch the "ANCHOR" element (either the text or anywhere in the black box, I don't think it matters), and immediately drag up/down to scroll the page. Release your finger.
3. If the anchor element got a colorful background, tap elsewhere (e.g. the "DIV") so that ANCHOR loses its background.
4. Repeat steps 2-3, waiting shorter/longer amounts between touching the screen and when you drag up/down.

ACTUAL RESULTS:
In Firefox, the anchor element only gains a background (a hover-state) when you've long-pressed it (without yet scrolling) for long enough to trigger a context-menu.

EXPECTED RESULTS:
In Chrome, the anchor element gains a background when you've long-pressed it (without yet scrolling) for a short amount of time, which is shorter than the time that it takes to trigger the context-menu.

This ends up meaning that it's possible to trigger the hover-state without triggering a context-menu (and without actually navigating to the link-target) in Chrome, but not in Firefox.

I'm not sure this area (:hover on Android) is well-specced, but it's perhaps worth considering whether Chrome's behavior here makes any sense and is worth aligning on for compat. We do have one webcompat site-report that was filed about this (bug 1907805) though it's not clear the use-case-that-works-in-Chrome-but-not-Firefox there (making :hover preview images appear by touching and scrolling) is particularly robust or by-design.

Hi Makoto!
Would love to know your thoughts about a path forward. Does it make sense that we align our behavior to Chrome? How big the effort is if we plan to do the change? Thank you.

Comment 4

[Makoto Kato [:m_kato]]

It seems to be APZ behavior. Botond, could you look this by APZ team?

Comment 5

[Botond Ballo [:botond]]

Sure, will discuss with the team and follow up on this.

For reference, the relevant code for activating elements in response to touch gestures is in ActiveElementManager.cpp and its uses in APZEventState.cpp.

Comment 6

[Alex Jakobi [:ajakobi]]

Attachment: Behavior Safari on iOS

I've captured a screen recording on iOS 18.2. Hope this gives a good impression of the behavior, please let me know should I test differently.
Link: https://drive.google.com/file/d/1bZKcfTdZDggH21SIzRy6mFswJ65xLiXr/view?usp=sharing

Comment 7

[Botond Ballo [:botond]]

Discussed this in today's APZ meeting.

(In reply to Hsin-Yi Tsai (she/her) [:hsinyi] from comment #3)

Does it make sense that we align our behavior to Chrome?

We've verified that Safari also has similar behaviour to Chrome, so we think it would make sense to align with this behaviour as well.

How big the effort is if we plan to do the change?

One thing I overlooked when writing comment 5 is that the :hover state is not directly managed by ActiveElementManager (I was thinking of the :active state, I confused the two). However, the activation of the :hover state is still likely to be an indirect result of actions taken to handle the tap gesture in APZEventState.

We're tracking this for further investigation (and hopefully a fix, if we don't run into any major hurdles) in FFXP-3024.

Comment 8

[Frank Griffith Jr]

Have captured this as part of Jira Epic APZ Android Sprint Part V

Comment 9

[Botond Ballo [:botond]]

Note for when we start work on this: re-test the affected scenarios once bug 1633450 has landed, in case it has improved some of them.

Comment 10

[Hiroyuki Ikezoe (:hiro)]

Attachment: Another test case replicating bug 1907805

Here is another test case, which is closer to what the site in bug 1907805 does.

In this test case there's an APZ aware event listener (touchmove) so that calling ActiveElementManager::HandleTouchStart slightly delays.

This test case realized me that changing :hover state needs to be triggered, i.e. needs to start a timer without waiting for the response from the content. As far as I can tell that's what chrome does.

Comment 11

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1919411 - Rename ActiveElementManager to ElementStateManager. r?botond

We will use ElementStateManager for :hover state setting.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1919411 - Factor out the code for scheduling SetActiveTask. r?botond

Comment 13

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1919411 - Rename CancelTask to CancelSetActiveTask. r?botond

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1919411 - Drop trailing line-feeds in MOZ_LOG. r?botond

Comment 15

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1919411 - Set :hover state on touch events, similar to what we do for :active. r?botond

There are two differences from :active state.

1. A setting :hover state task is triggered right after the initial
   touchstart event is dispatched to the content, i.e. unlike :active
   we don't wait for APZStateChange::eStartTouch notification that the
   result comes from an APZC which has started using the touchstart event

2. ElementStateManager will never unset :hover state explicitely, :hover
   state will be unset implicitly when a new :hover element is set or
   some other events such as mouseout

These :hover behaviors match Chrome (our :active behaviors don't match
Chrome though, the timing when Chrome sets :hover looks same as :active).

There are three test cases for 1),
helper_hover_state_with_touch_action_none.html:
:hover is set on touch-action:none elements
helper_hover_state_with_prevent_default_on_touchmove.html:
:hover is set even if touchmove is preventDefaulted
helper_hover_state_while_scroll.html:
:hover is set even if the content is being scrolled by the touch events

helper_hover_state_while_scroll.html is also for 2), i.e. :hover state
keeps being applied even after scrolling happens.

One caveat here is that on Chrome :hover state is never set if the
initial touchstart event is preventDefaulted. This case is handled in
the next change.

Comment 16

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1919411 - Do not set :hover state if the touchstart event was preventDefault-ed. r?botond

Comment 17

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b1f2edb6a23c
https://hg.mozilla.org/integration/autoland/rev/73bdafc265df
Rename ActiveElementManager to ElementStateManager. r=botond
https://github.com/mozilla-firefox/firefox/commit/8fec3c7ae394
https://hg.mozilla.org/integration/autoland/rev/52cdcab4f66c
Factor out the code for scheduling SetActiveTask. r=botond
https://github.com/mozilla-firefox/firefox/commit/772c43399536
https://hg.mozilla.org/integration/autoland/rev/20ab17adc7ba
Rename CancelTask to CancelSetActiveTask. r=botond
https://github.com/mozilla-firefox/firefox/commit/1ff48cd40aba
https://hg.mozilla.org/integration/autoland/rev/af0a7ceda469
Drop trailing line-feeds in MOZ_LOG. r=botond
https://github.com/mozilla-firefox/firefox/commit/ec83175bffb0
https://hg.mozilla.org/integration/autoland/rev/85301eef34c8
Set :hover state on touch events, similar to what we do for :active. r=botond
https://github.com/mozilla-firefox/firefox/commit/0e0418a045c0
https://hg.mozilla.org/integration/autoland/rev/25bc73b6f140
Do not set :hover state if the touchstart event was preventDefault-ed. r=botond

Comment 18

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/b9d02bcfbff0
https://hg.mozilla.org/integration/autoland/rev/75f4f681813a
Revert "Bug 1919411 - Do not set :hover state if the touchstart event was preventDefault-ed. r=botond" for causing leaks

Comment 19

[Cristina Horotan [:chorotan]]

Backed out for causing leaks

Backout link

Push with failures

Failure log

Comment 20

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1919411 - Cancel scheduled :active and :hover setting tasks. r?botond

Otherwise these tasks will leak if the tasks were in the scheduled queue
when the target document is destroyed.

Comment 21

[Hiroyuki Ikezoe (:hiro)]

Posted D265039 to fix the failure (a leak).

In short it's kind pre-exising, our :active task has been also leaked there, but there was no test covering the case. I've added a new test covering the :active case as well as :hover case in the patch.

Comment 22

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1919411 - Cancel scheduled tasks owned by GestureEventListener when it's destroyed. r?botond

Comment 23

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/8f7bd5a3a74e
https://hg.mozilla.org/integration/autoland/rev/f2cd81177ee0
Rename ActiveElementManager to ElementStateManager. r=botond
https://github.com/mozilla-firefox/firefox/commit/349ac19f30cd
https://hg.mozilla.org/integration/autoland/rev/0b6acaa63fec
Factor out the code for scheduling SetActiveTask. r=botond
https://github.com/mozilla-firefox/firefox/commit/9adae67b8221
https://hg.mozilla.org/integration/autoland/rev/7964f764cbc2
Rename CancelTask to CancelSetActiveTask. r=botond
https://github.com/mozilla-firefox/firefox/commit/e870da71c93e
https://hg.mozilla.org/integration/autoland/rev/915417628d26
Drop trailing line-feeds in MOZ_LOG. r=botond
https://github.com/mozilla-firefox/firefox/commit/aa5aa0e26dee
https://hg.mozilla.org/integration/autoland/rev/4707377b107c
Set :hover state on touch events, similar to what we do for :active. r=botond
https://github.com/mozilla-firefox/firefox/commit/91f38f0634a6
https://hg.mozilla.org/integration/autoland/rev/a680bac172a6
Do not set :hover state if the touchstart event was preventDefault-ed. r=botond
https://github.com/mozilla-firefox/firefox/commit/9967c184c931
https://hg.mozilla.org/integration/autoland/rev/c371349d9191
Cancel scheduled tasks owned by GestureEventListener when it's destroyed. r=botond
https://github.com/mozilla-firefox/firefox/commit/9efd319f32ac
https://hg.mozilla.org/integration/autoland/rev/60bc16d960fe
Cancel scheduled :active and :hover setting tasks. r=botond

Comment 24

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/a7ceed3292da
https://hg.mozilla.org/integration/autoland/rev/f032c4daf9fa
Revert "Bug 1919411 - Cancel scheduled :active and :hover setting tasks. r=botond" for causing mochitest failures on test_group_touchevents-6.html

Comment 25

[Cristina Horotan [:chorotan]]

Backed out for causing muchitest failures

Backout link

Push with failures

Failure log

Comment 26

[Hiroyuki Ikezoe (:hiro)]

The new tests failed on non-fission runs. (I am a bit surprised there still exist non-fission runs).

We don't need to run the new tests specifically on non-fission runs.

Comment 27

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/49b9e07dbc85
https://hg.mozilla.org/integration/autoland/rev/1a5291c45f7f
Rename ActiveElementManager to ElementStateManager. r=botond
https://github.com/mozilla-firefox/firefox/commit/d113678d575c
https://hg.mozilla.org/integration/autoland/rev/d75d92ae0a25
Factor out the code for scheduling SetActiveTask. r=botond
https://github.com/mozilla-firefox/firefox/commit/096aa5eafe35
https://hg.mozilla.org/integration/autoland/rev/3792e90297a0
Rename CancelTask to CancelSetActiveTask. r=botond
https://github.com/mozilla-firefox/firefox/commit/4cd19cf0d737
https://hg.mozilla.org/integration/autoland/rev/69c219a16ebc
Drop trailing line-feeds in MOZ_LOG. r=botond
https://github.com/mozilla-firefox/firefox/commit/ad7d99864389
https://hg.mozilla.org/integration/autoland/rev/e420ba8f1aba
Set :hover state on touch events, similar to what we do for :active. r=botond
https://github.com/mozilla-firefox/firefox/commit/ece5556018cc
https://hg.mozilla.org/integration/autoland/rev/615e00e7d630
Do not set :hover state if the touchstart event was preventDefault-ed. r=botond
https://github.com/mozilla-firefox/firefox/commit/807533b4e734
https://hg.mozilla.org/integration/autoland/rev/d269fde7d16f
Cancel scheduled tasks owned by GestureEventListener when it's destroyed. r=botond
https://github.com/mozilla-firefox/firefox/commit/b93456329305
https://hg.mozilla.org/integration/autoland/rev/34342a576506
Cancel scheduled :active and :hover setting tasks. r=botond

Comment 28

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/51a45ab9ff9f
https://hg.mozilla.org/integration/autoland/rev/2ec92a1807ff
Revert "Bug 1919411 - Cancel scheduled :active and :hover setting tasks. r=botond" for causing mochitest-plain failures on test_group_touchevents-6.html.

Comment 29

[Iulian Moraru]

Revert for causing mochitest-plain failures on test_group_touchevents-6.html.

• Push with failures

• Failure log

• Backout link

[task 2025-09-19T06:47:23.987+00:00] 06:47:23     INFO -  TEST-START | gfx/layers/apz/test/mochitest/test_group_touchevents-6.html
[task 2025-09-19T06:53:57.885+00:00] 06:53:57     INFO -  wait for org.mozilla.geckoview.test_runner complete; top activity=org.mozilla.geckoview.test_runner
[task 2025-09-19T06:53:57.886+00:00] 06:53:57     INFO -  org.mozilla.geckoview.test_runner unexpectedly found running. Killing...
[task 2025-09-19T06:54:11.278+00:00] 06:54:11  WARNING -  TEST-UNEXPECTED-FAIL | gfx/layers/apz/test/mochitest/test_group_touchevents-6.html | application timed out after 370 seconds with no output
[task 2025-09-19T06:54:11.278+00:00] 06:54:11     INFO -  runtestsremote.py | Application ran for: 0:08:35.470814
[task 2025-09-19T06:54:11.360+00:00] 06:54:11     INFO -  runtests.py | Running http tests: end. status: 1
[task 2025-09-19T06:54:11.360+00:00] 06:54:11     INFO -  Stopping web server
[task 2025-09-19T06:54:11.362+00:00] 06:54:11     INFO -  Server shut down.
[task 2025-09-19T06:54:11.362+00:00] 06:54:11     INFO -  Web server killed.
[task 2025-09-19T06:54:11.362+00:00] 06:54:11     INFO -  Stopping web socket server
[task 2025-09-19T06:54:11.362+00:00] 06:54:11     INFO -  Stopping ssltunnel
[task 2025-09-19T06:54:11.604+00:00] 06:54:11     INFO -  Buffered messages logged at 06:47:23
[task 2025-09-19T06:54:11.605+00:00] 06:54:11     INFO -  TEST-PASS | gfx/layers/apz/test/mochitest/test_group_touchevents-6.html | Check if TouchEvent is supported (it should be, the test harness forces it on everywhere)
[task 2025-09-19T06:54:11.605+00:00] 06:54:11     INFO -  TEST-PASS | gfx/layers/apz/test/mochitest/test_group_touchevents-6.html | Starting subtest helper_event_during_fast_fling.html

Comment 30

[Hiroyuki Ikezoe (:hiro)]

The failure task is M-fis-hv, which is that example.com is not loading out of process.

I've updated D265039 to skip the tests on fis-hv tasks.

I will land these change tomorrow morning.

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/fbd8f8b153aa
https://hg.mozilla.org/integration/autoland/rev/23ca6658ec29
Rename ActiveElementManager to ElementStateManager. r=botond
https://github.com/mozilla-firefox/firefox/commit/bec72cecdab7
https://hg.mozilla.org/integration/autoland/rev/9a0aeed42532
Factor out the code for scheduling SetActiveTask. r=botond
https://github.com/mozilla-firefox/firefox/commit/7c193833319a
https://hg.mozilla.org/integration/autoland/rev/7c852a62abad
Rename CancelTask to CancelSetActiveTask. r=botond
https://github.com/mozilla-firefox/firefox/commit/e0f9fcd122ad
https://hg.mozilla.org/integration/autoland/rev/4b4982f8d383
Drop trailing line-feeds in MOZ_LOG. r=botond
https://github.com/mozilla-firefox/firefox/commit/cf0f4e6f011e
https://hg.mozilla.org/integration/autoland/rev/185e4f6e570d
Set :hover state on touch events, similar to what we do for :active. r=botond
https://github.com/mozilla-firefox/firefox/commit/a40e9c56bcd4
https://hg.mozilla.org/integration/autoland/rev/2761d187e9dd
Do not set :hover state if the touchstart event was preventDefault-ed. r=botond
https://github.com/mozilla-firefox/firefox/commit/ea428a68682c
https://hg.mozilla.org/integration/autoland/rev/3b54f91fe6a9
Cancel scheduled tasks owned by GestureEventListener when it's destroyed. r=botond
https://github.com/mozilla-firefox/firefox/commit/7555a8a5fbbc
https://hg.mozilla.org/integration/autoland/rev/19f29c60f99b
Cancel scheduled :active and :hover setting tasks. r=botond

Comment 32

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/23ca6658ec29
https://hg.mozilla.org/mozilla-central/rev/9a0aeed42532
https://hg.mozilla.org/mozilla-central/rev/7c852a62abad
https://hg.mozilla.org/mozilla-central/rev/4b4982f8d383
https://hg.mozilla.org/mozilla-central/rev/185e4f6e570d
https://hg.mozilla.org/mozilla-central/rev/2761d187e9dd
https://hg.mozilla.org/mozilla-central/rev/3b54f91fe6a9
https://hg.mozilla.org/mozilla-central/rev/19f29c60f99b