1716328 - horizontal scrolling with arrow keys in multi-column box with scroll-snap is broken

Status: NEW

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

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:89.0) Gecko/20100101 Firefox/89.0

Steps to reproduce:

see https://codepen.io/gunnarbittersmann/pen/dyvQYaJ
box with role="group" tabindex="0", column-width, and scroll-snap-type: x mandatory
set focus onto the box, press arrow-right key to scroll forwards (this works)
then press arrow-left key to scroll back

Actual results:

scrolling back with arrow-left key does not work

Expected results:

one should be able scrolling back with arrow-left key

Comment 1

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

The Bugbug bot thinks this bug should belong to the 'Core::Disability Access APIs' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[[e-mail]]

I could reproduce this bug on macOS and Windows. I’ve been told that the Linux version is not affected.

Comment 3

[Morgan Reschenberg [:morgan]]

I'm not sure if this belongs in Disability APIs since it isn't a screen reader issue -- its an issue with arrow-key scrolling at large. It also seems to occur in containers with particular style. Triage'ing over to layout because of that (feel free to NI if this is the wrong place)

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

This seems quite odd! Here's a reduced testcase. The issue goes away if I remove the font-family: Calibri, for some reason, though that might just be because there's some sizing threshold that needs to be tripped in order to trigger the bug, and Calibri happens to be a font whose metrics meet this threshold.

Comment 5

[Daniel Holbert [:dholbert]]

hiro, maybe you could take a look when you have cycles? Looking at dependencies of bug 1231777, it looks like you're the right person to ask about scroll-snapping. :)

Comment 6

[Hiroyuki Ikezoe (:hiro)]

Though I will have a look later, this depends on toolkit.scrollbox.horizontalScrollDistance value I think?

Comment 7

[Hiroyuki Ikezoe (:hiro)]

Though I haven't debugged at all, but I am almost 100% sure, there is a problem in AsyncPanZoomController::MaybeAdjustDestinationForScrollSnapping, in the case of scrolling by keyboard we shouldn't try to get the final destination position with the given scroll destination.

Comment 8

[Botond Ballo [:botond]]

One thing worth checking here is what the behaviour is with apz.keyboard.enabled=false (i.e. taking the main-thread keyboard scrolling codepath).

If that's also incorrect, it's important to fix both codepaths (APZ and main-thread) because, for keyboard scrolling in particular, there is no guarantee we'll take the APZ codepath (e.g a key listener could cause us not to).