1628987 - scroll disabled on touchmove with transform

Status: REOPENED

(Core :: Web Painting, defect, P2)

Description

[thomas.welter]

Attachment: tes.html

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.163 Safari/537.36

Steps to reproduce:

1. Launch the html file
2. swipe down and then release (causing the div to animate back into position)
3. scrolling is now disabled

Actual results:

Scrolling is not working in the following sitations:

1. scrolling with two fingers on the trackpad
2. scrolling using the touchscreen on my laptop

Scrolling can be made working again by:

1. clicking the scrollbar
2. switching tabs

This seems influenced by the translateY transform on line 103. When i translate by any amount other then 0 this issue appears.

Expected results:

I expect passive event listeners to not affect scrolling behavior. The current behavior of disabling scrolling until switching tabs seems especially strange.

Comment 1

[thomas.welter]

Note: Just switching tabs doesn't seem to be enough. Switching windows seems to work and switching tabs and then scrolling in another tab also seems to work

Comment 2

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

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Comment 3

[Emilio Cobos Álvarez (:emilio)]

This seems related probably to how APZ handles focus...

Comment 4

[Emilio Cobos Álvarez (:emilio)]

I can repro with a touch screen on desktop linux (using WebRender, FWIW).

Comment 5

[Emilio Cobos Álvarez (:emilio)]

Seems to repro as well on Firefox 70 with WR disabled.

Comment 6

[Kartikaya Gupta (email:[e-mail])]

I don't have a touchscreen laptop on hand to test but I can reproduce in Fennec (landscape orientation to make the page scrollable). Not in Fenix though. Strange. For touch-driven scrolling attempts I might guess that resetting the div's transform during the touchmove causes the APZ scroll to get interrupted by rebuilding the layer tree or something, but that wouldn't explain why scrolling "with two fingers on the trackpad" would break, because that shouldn't be triggering any of the listeners on the page.

This will need some investigation on a machine with a touchscreen. I'll try digging out a Windows touchscreen laptop that I have and see if I can repro there and/or get logs.

Comment 7

[Kartikaya Gupta (email:[e-mail])]

I can repro on a Windows touchscreen laptop now. I turned on various APZ logging and the results are puzzling but inconclusive. Seems like we immediately go from state TOUCHING into state NOTHING once we have a pan that exceeds the movement threshold. The NOTHING state consumes all the touchmove events without doing any panning. I'm not sure why we go into the NOTHING state, I presume it's happening inside this call but I'll add more logging to figure out exactly what's happening.

Comment 8

[Kartikaya Gupta (email:[e-mail])]

Seems like the layer tree changes such that there's a HTTN for the root content sitting on top of everything else and getting the touch events. The root content isn't scrollable so nothing scrolls. Need to dig into the display list/layers tree to see why that HTTN is coming out where it is.

Comment 9

[Kartikaya Gupta (email:[e-mail])]

Attachment: DL/layer dump before overscroll transform

Comment 10

[Kartikaya Gupta (email:[e-mail])]

Attachment: DL/layer dump after overscroll transform

Seems like there's a stray CompositorHitTestInfo item at the end of the display list (after the nsDisplayTransform and all its underlings) that ends up creating a new [not visible] layer but that has hit-test info. That's the layer that that ends up on top of everything and consuming the input.

I don't know what frame is generating that display item yet since the frame doesn't match anything else in the DL dump. Will need to get a frame dump too.

Comment 11

[Firefox Bug Husbandry Bot]

Resetting severity to default of --.

Comment 12

[Kartikaya Gupta (email:[e-mail])]

Attachment: Frame dump + DL + layer tree

Here's output including a frame dump. The CompositorHitTestInfo display item seems to be coming from the block frame for the body element, which seems wrong, since any hit-test items from the body should go under the transformed scrollframe, not on top.

Comment 13

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

The priority flag is not set for this bug.
:mattwoodrow, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 14

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

The priority flag is not set for this bug.
:mattwoodrow, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 15

[Firefox Bug Husbandry Bot]

Because this bug's Severity has not been changed from the default since it was filed, and it's Priority is -- (Backlog,) indicating it has has not been previously triaged, the bug's Severity is being updated to -- (default, untriaged.)

Comment 16

[Rachel Tublitz [:rachel]]

S1 or S2 bugs needs an assignee - could you find someone for this bug?

Comment 17

[Kartikaya Gupta (email:[e-mail])]

I was hoping to hand this off to you (Matt) or Miko or somebody else who has a better handle on DL building code...

Comment 18

[janet [:janet]]

Marking this as S3 as it appears that S2 (Serious) Major functionality/product severely impaired - is not the correct severity here. Please update if this is incorrectly categorized.

Comment 19

[Botond Ballo [:botond]]

Thomas, can you still reproduce this in a recent Firefox version?

Comment 20

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

Redirect a needinfo that is pending on an inactive user to the triage owner.
:tnikkel, since the bug has recent activity, could you have a look please?

For more information, please visit BugBot documentation.

Comment 21

[Timothy Nikkel (:tnikkel)]

?? Don't see any reason why this should be closed.

Comment 22

[Marco Castelluccio [:marco]]

I assumed it was no longer reproducible.

Comment 23

[Timothy Nikkel (:tnikkel)]

I don't see that in the bug history.

Comment 24

[Marco Castelluccio [:marco]]

Yeah, my bad, I didn't read the whole history, I only read starting from recent comments (comment 19).

Comment 25

[Timothy Nikkel (:tnikkel)]

I don't want to be a pedant here, but I think this point is important: I don't see evidence of lack of reproducibility when starting from comment 19.

Comment 26

[Marco Castelluccio [:marco]]

OK, is there something else I can do to rectify my wrong assumption other than offering my apology?

Comment 27

[Timothy Nikkel (:tnikkel)]

I was clarifying things, not trying to flog you.