1755194 - When using touchscreen, touched UI elements remain in their ":hover" highlighted state for too long; the highlight remains even after you touch the web content area

Status: NEW

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

Description

[James Heppell [:FormularSumo]]

Attachment: 2022-02-13 14-46-41_Trim.mp4

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:97.0) Gecko/20100101 Firefox/97.0

Steps to reproduce:

Tap on a UI element such as downloads and then tap anywhere on a webpage

Actual results:

UI element remains selected and highlighted

Expected results:

UI element should deselect like it does when you move mouse off of it

Comment 1

[Ada C.]

Thanks for reporting, James!

I tried to reproduce this issue on Windows 10 using Firefox 97, but unfortunately I couldn't recreate the situation.


Can you test the issue while in Safe Mode? You can find helpful info here: https://support.mozilla.org/en-US/kb/troubleshoot-firefox-issues-using-safe-mode.
Also a fresh new profile could help: https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems#w_6-create-a-new-firefox-profile.

Comment 2

[James Heppell [:FormularSumo]]

I tested with a fresh profile in safe mode but the issue persists. Just to check you are using a touchscreen to test? It doesn't happen when using a mouse/touchpad. It seems to me that moving the mouse causes the UI to check whether anything should be selected, but when a touchscreen is used it doesn't count the mouse cursor as having moved so they remain selected. Maybe a fix would be having the UI check whether it should be selected whenever there's a mouse click (or specifically a touchscreen tap) as well as when there's mouse movement?

I used to get the issue on Windows 10 as well as 11 now, with all versions of Firefox I've tried.

Comment 3

[Brindusa Tot, DTE]

Setting this to NEW as I can reproduce it using the latest Nightly 99.0a1, Firefox 98 beta 9 and Firefox 97.0.1, against Windows 10 on a SurfacePro with touchscreen.

Comment 4

[BugBot [:suhaib / :marco/ :calixte]]

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

For more information, please visit auto_nag documentation.

Comment 5

[Daniel Holbert [:dholbert]]

This behavior (targeting/delivery of touchscreen events) probably is more under the umbrella of DOM:Events than layout, I think.

I think the "highlighted" state that seems to be stuck-on here is actually the thing rendering as if it were hovered; i.e. it's rendering its :hover state.

Rough theory about what's going on:

• the frontend process seems to see the touch event as implicitly including a signal to behave as if the cursor is hovered at the touched point.
• If you then touch a piece of your web content, that event apparently goes directly to the content process; and we fail to inform the frontend process that the cursor is now somewhere else.

One experiment to demonstrate/backup this theory: if you perform the STR on about:preferences or about:support (which render in the frontend process), then the bug doesn't reproduce; the toolbar button loses its hover-highlighting as soon as you tap the content area. But if you perform the STR on e.g. https://example.org , then the bug does reproduce.

Comment 6

[Daniel Holbert [:dholbert]]

FWIW: I'm testing and easily-able-to-reproduce this on my 2015-era Microsoft Surface 3, in Windows 10 with Firefox Nightly. My STR are to just touch the hamburger menu (which opens it) and then touch a blank spot in the web content area (which closes the menu, but its button remains highlighted as if it were still hovered.

Comment 7

[Daniel Holbert [:dholbert]]

Interestingly, I can't reproduce this in Linux on the same device (following the same STR). This seems to be Windows-specific.

Comment 8

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

Do you know if it's more a win widget issue?

Comment 9

[Edgar Chen [:edgar]]

I found that this doesn't reproduce on 50, I got https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=59db3b0781908d9e2145477ff8dc5a85729e25bf&tochange=87cd291d2db621da6b3eb1057027cc0725b6eb1d from mozregression. Smell like a regression of bug 1300203.

Comment 10

[Daniel Holbert [:dholbert]]

(In reply to Edgar Chen [:edgar] from comment #9)

Smell like a regression of bug 1300203.

Agreed:

• That bug's patch is windows-specific (and this is a Windows-specific bug per comment 7).
• That bug's commit message mentions sLastMouseMovePoint which sounds like the name of the exact concept that I was getting at in comment 5; essentially, in this bug here, we seem to be failing to update the last-moved-mouse-point when you touch the content area. (which is why the hover state is sticking around for too long)

I guess we should update this to match component of bug 1300203.

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

:kats, since you are the author of the regressor, bug 1300203, could you take a look?
For more information, please visit auto_nag documentation.

Comment 12

[Daniel Holbert [:dholbert]]

redirecting ni=kats to botond, since kats isn't actively working on Mozilla APZ stuff anymore.

Comment 13

[Botond Ballo [:botond]]

Thanks, I've added the issue to the APZ team backlog.

Comment 14

[BugBot [:suhaib / :marco/ :calixte]]

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