1724759 - Firefox does not remove the active pseudo class from button once the button is pressed by a long tap, and then released

Status: RESOLVED FIXED

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

Description

[Kevin Brosnan [Ex-Mozilla]]

From github: https://github.com/mozilla-mobile/fenix/issues/20606.

Steps to reproduce

Below is some simple code to reproduce the behaviour.

The css used for the button:

.button {
background: white;
font-size: 40px;
font-weight: bold;
height: 100%;
width: 100%;
}

.button:active {
background-color: #f3f3f3;
color: black;
}

<div style="width: 100%;height: 100%">
<button class="button" >Button </button>
</div>

Expected behaviour

After pressing, holding and finally releasing the button, the background should return to white.

Actual behaviour

When the button is pressed, held and then released the button background colour remains #f3f3f3. That behaviour is present in Firefox on Android only, the Firefox for iOS works as expected.

Device name

Samsung S9, Google Pixel C tablet

Android version

10 on S9, 8.1.0 on Pixel C

Firefox release type

Firefox

Firefox version

90.1.3 on S9, 90.1.2 on Pixel C

Device logs

No response

Additional information

No response

Change performed by the Move to Bugzilla add-on.

Comment 1

[Kevin Brosnan [Ex-Mozilla]]

Attachment: 1724759.html

Comment 2

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

It seems the behavior is same on Windows except that it opens an actual context menu. Since this is styling related:

Comment 3

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Actually I guess it needs more investigation.

Comment 4

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Chrome on Windows tend to (but somehow not always) remove the active state when the touch contact is removed and then opens a context menu, while Gecko always keeps the active state.

This is seemingly because EventStateManager::PostHandleEvent only calls ClearGlobalActiveContent on mouseup event and the long touch gesture does not fire a mouseup event but only contextmenu event.

Comment 5

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Attachment: Bug 1724759 - Clear active state when context menu opens r=smaug

Comment 6

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

This now confuses me since Chrome behaves differently on Windows and Android.

On this example https://codepen.io/SaschaNaz/pen/ZEyGQPR (You can open arrow button->Console to read it on mobile):

• On Windows, when holding touch contact on the button, Chrome keeps the active state, just as Firefox does.
• On Android, Chrome clears the active state. The timing is unknown, it does not clear during the context menu event or right after it, but some unknown time after that. I'm not sure this is even intended.

:smaug, what do you think? I'm not sure what the patch should look like. Maybe I should file the issue on Chromium instead?

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

I would expect active state to be cleared when touch is removed, at latest.

Does Chrome on Windows not clear the active state ever?

Comment 8

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

(In reply to Olli Pettay [:smaug] from comment #7)

I would expect active state to be cleared when touch is removed, at latest.

Does Chrome on Windows not clear the active state ever?

It does but not after a touch hold (for 500+ ms I guess), which is exactly what this bug is about.

Comment 9

[Kagami Rosylight 🏳️‍🌈🏳️‍⚧️ [:saschanaz] (they/them)]

Unassigning myself from inactive bugs. Please retriage.

Comment 10

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

Currently, it affects only for the pseudo-class. I think that we should give higher priority if this causes a web-compat issue in web apps in the wild.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

This is a sort of an APZ issue. On a touchend event;

• APZ resets the active state if the touchend event wasn't for click
• Whether the touchend event was click is depending on aArg in APZEventState::ProcessAPZStateChange
• The aArg value come from SetSingleTapOccurred call in AsyncPanZoomController::GenerateSingleTap
• The GenerateSingleTap is also called for longpress case not only for single-tap.

So I would say that a proper fix is not to call SetSingleTapOccurred in the case of longpress events.

Comment 13

[Hiroyuki Ikezoe (:hiro)]

Oops, I forgot saying an important fact. We don't fire any click events on the longpress event case.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1724759 - Skip calling SetSingleTapOccurred for long-tap events. r?botond

Comment 15

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/4d738f187f15
Skip calling SetSingleTapOccurred for long-tap events. r=botond

Comment 16

[Sandor Molnar[:smolnar]]

https://hg.mozilla.org/mozilla-central/rev/4d738f187f15