1895742 - Pull to refresh triggers on navigating a geographic map

Status: RESOLVED FIXED

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

Description

[eclaudiu64]

Attachment: mobizen_20240508_190145.mp4

User Agent: Mozilla/5.0 (Android 11; Mobile; rv:127.0) Gecko/127.0 Firefox/127.0

Steps to reproduce:

Accessed site: https://www.meteoromania.ro/vremea/prognoza-meteo/prognoza-12-ore/ , pull to refresh is triggered when pulled, on the interactive geographic map. The map appears to be located right at the top of the site.

Actual results:

Pull to refresh is triggered when the screen is pulled down, right on pressing the map.

Expected results:

Pull to refresh should not fire on an interactive map.

Comment 1

[eclaudiu64]

Can you take a look and maybe put it on the list for pull to refresh errors?

Comment 2

[Chris Peterson [:cpeterson]]

Linking this bug to meta bug 1882722 with other pull-to-refresh bugs.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

I am not yet sure what's going on there, but I would say it's an issue in Gecko not in Fenix.

On the site, I've often see nsEventStatus_eConsumeNoDefault should involve a valid APZHandledResult assertions. And moreover Fenix receives an InputResultDetail for MotionEvent.ACTION_MOVE first, then receives the InputResultDetail for MotionEvent.ACTION_DOWN. It's completely broken.

Comment 4

[Hiroyuki Ikezoe (:hiro)]

Attachment: A test case

A similar case to bug 1897345 one, but no event listener.

Comment 5

[Botond Ballo [:botond]]

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)

On the site, I've often see nsEventStatus_eConsumeNoDefault should involve a valid APZHandledResult assertions. And moreover Fenix receives an InputResultDetail for MotionEvent.ACTION_MOVE first, then receives the InputResultDetail for MotionEvent.ACTION_DOWN. It's completely broken.

This sounds like the sort of thing that may potentially be fixed by bug 1897567.

Comment 6

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #5)

(In reply to Hiroyuki Ikezoe (:hiro) from comment #3)

On the site, I've often see nsEventStatus_eConsumeNoDefault should involve a valid APZHandledResult assertions. And moreover Fenix receives an InputResultDetail for MotionEvent.ACTION_MOVE first, then receives the InputResultDetail for MotionEvent.ACTION_DOWN. It's completely broken.

This sounds like the sort of thing that may potentially be fixed by bug 1897567.

Maybe not, since the delayed result for the ACTION_DOWN event is HANDLED.

Comment 7

[Botond Ballo [:botond]]

(In reply to Botond Ballo [:botond] from comment #6)

Maybe not, since the delayed result for the ACTION_DOWN event is HANDLED.

The map element does use touch-action: none, so the result should be an eager HANDLED_CONTENT.

Comment 8

[Hiroyuki Ikezoe (:hiro)]

(In reply to Botond Ballo [:botond] from comment #7)

(In reply to Botond Ballo [:botond] from comment #6)

Maybe not, since the delayed result for the ACTION_DOWN event is HANDLED.

The map element does use touch-action: none, so the result should be an eager HANDLED_CONTENT.

In this specific case, we don't have aTouchBehaviors on the ReceiveTouchInput call, thus we don't yet have the allowed-touch-behaviors so that we need to wait for a content response. That means we need to do the same thing we did in bug 1785754 in here in GetHandledResultFor.

Comment 9

[Hiroyuki Ikezoe (:hiro)]

Attachment: Bug 1895742 - Return HandledByContent for touches prevented by touch-action. r?botond

Similar to what we did in bug 1785754, specifically in
hg.mozilla.org/integration/autoland/rev/e05ed4cedf9f , but not eager cases.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/020d2296a729
Return HandledByContent for touches prevented by touch-action. r=botond,geckoview-reviewers,tthibaud

Comment 11

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/020d2296a729

Comment 12

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

Since nightly and release are affected, beta will likely be affected too.
For more information, please visit BugBot documentation.

Comment 13

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

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

• If yes, please nominate the patch for beta approval.
• If no, please set status-firefox128 to wontfix.

For more information, please visit BugBot documentation.

Comment 14

[Hiroyuki Ikezoe (:hiro)]

Comment on attachment 9405394 [details]
Bug 1895742 - Return HandledByContent for touches prevented by touch-action. r?botond

Beta/Release Uplift Approval Request

• User impact if declined: Users on Android will keep suffering from unexpected contents reload by pull-to-refresh (i.e. users will lose something they did on the contents, e.g typing messages some such)
• Is this code covered by automated tests?: Yes
• Has the fix been verified in Nightly?: Yes
• Needs manual test from QE?: No
• If yes, steps to reproduce:
• List of other uplifts needed: none
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): The change is small, and also it's limited to in a certain condition, on Android with pull-to-refresh
• String changes made/needed: none
• Is Android affected?: Yes

Comment 15

[Donal Meehan [:dmeehan]]

Comment on attachment 9405394 [details]
Bug 1895742 - Return HandledByContent for touches prevented by touch-action. r?botond

Approved for 128.0b8

Comment 16

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-beta/rev/85e4d10d626c