Open Bug 1716328 Opened 2 years ago Updated 2 years ago

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


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

Firefox 89




(Reporter: gunnar, Unassigned)


(Keywords: access, Whiteboard: [access-s3])


(1 file)

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

Steps to reproduce:

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

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.

Component: Untriaged → Disability Access APIs
Product: Firefox → Core

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

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)

Component: Disability Access APIs → Layout: Scrolling and Overflow
Keywords: access
Summary: horizontal scrolling with arrow keys in multi-column box with scroll-snap → horizontal scrolling with arrow keys in multi-column box with scroll-snap is broken
Whiteboard: [access-s3]
Attached file 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.

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. :)

Severity: -- → S3
Ever confirmed: true
Flags: needinfo?(hikezoe.birchill)

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

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.

Component: Layout: Scrolling and Overflow → Panning and Zooming
Flags: needinfo?(hikezoe.birchill)
Priority: -- → P3

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).

You need to log in before you can comment on or make changes to this bug.