1789815 - horizontal-scrollable element stops slightly diagonal up/down pans but doesn't scroll itself

Status: NEW

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

Description

[Timothy Nikkel (:tnikkel)]

I'm testing on macOS on latest nightly. Load the page https://bugzilla.mozilla.org/show_bug.cgi?id=1782339 and put your mouse pointer in the middle of the page and then try to scroll completely through the page using a series of small up/down pans that are slightly diagonal. Frequently the scroll will stop momentarily when my mouse is over one of the horizontally-only scrollable elements, but the horizontally-only scrollable elements will neither scroll nor overscroll.

Comment 1

[Botond Ballo [:botond]]

Same category of issue as bug 1746967?

Comment 2

[Timothy Nikkel (:tnikkel)]

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

Same category of issue as bug 1746967?

I don't think so? I don't think there is any prevent default involved here?

Comment 3

[Botond Ballo [:botond]]

I mean in the generalized sense discussed in bug 1746304 comment 5: it's an issue with doing a new hit-test for a subsequent event in a pan gesture, versus reusing the result of the hit test for the first event.

Comment 4

[Timothy Nikkel (:tnikkel)]

I don't think so? It seems like we are doing a new hittest, that stops the scrolling of the main page, but when we apply the pan to the element underneath the cursor we do not scroll or overscroll it. So there seems to be a disconnect between the result of the hittest (saying scroll this other scroll frame) and performing actual scrolling (does not perform any type of scrolling on the "other" element). And then if we do another pan we do another hittest presumably, we are still over the same element, but now the hittest results in us scrolling the main page again? And these are small pan gestures, so we should be doing a new hittest when we start the new pan. Here I am lifting my fingers, so should be a new input block, bug 1746304 comment 5 seems to be about one input block and/or momentum.

Comment 5

[Botond Ballo [:botond]]

(In reply to Timothy Nikkel (:tnikkel) from comment #4)

It seems like we are doing a new hittest, that stops the scrolling of the main page, but when we apply the pan to the element underneath the cursor we do not scroll or overscroll it. So there seems to be a disconnect between the result of the hittest (saying scroll this other scroll frame) and performing actual scrolling (does not perform any type of scrolling on the "other" element).

This part could be related to dominant axis scrolling, if the subframe is only horizontally scrollable and the pan gesture is diagonal but closer to vertical.

And then if we do another pan we do another hittest presumably, we are still over the same element, but now the hittest results in us scrolling the main page again? And these are small pan gestures, so we should be doing a new hittest when we start the new pan. Here I am lifting my fingers, so should be a new input block, bug 1746304 comment 5 seems to be about one input block and/or momentum.

I don't have a theory about this part though (but I agree that this tells us something more is going on than just bug 1746967 -- thanks for clarifying).

Comment 6

[Botond Ballo [:botond]]

It would be interesting to know if this is a regression (and if so, get a regression window).

Comment 7

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

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

Comment 8

[Dan Robertson (:dlrobertson)]

This is definitely a regression introduced by dominant axis locking. When I set apz.axis_lock.mode to STICKY, I'm able to scroll https://bugzilla.mozilla.org/show_bug.cgi?id=1782339 just fine with a largely horizontal (but still slightly vertical) gestures. I think to fix this we need to check if we can scroll on the axis with the larger delta before truncating the smaller, once we enter this block. However, we need to also truncate the smaller delta if we can trigger an overscroll animation or an overscroll hand-off on the axis with the larger delta.

Comment 9

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

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

Comment 10

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

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

For more information, please visit auto_nag documentation.

Comment 11

[Botond Ballo [:botond]]

Having discussed this with Timothy and Dan, will mark this as S3 as a regression which has taken a few releases to be noticed, and we're not aware of any other users having reported it. Setting priority to P2 though as this is potentially annoying and would be nice to fix.