https://bugs.webkit.org/show_bug.cgi?id=48543

It seems ChromeOS makes Shift+Wheel to horizontal scroll[1]

[1] http://crbug.com/514828 ⚐	Shift + vertical scroll = horizontal scroll

I think the shift-wheel horizontal scroll is a Linux convention too.

The only things I imagine being tricky here are:

1) The wheel event probably doesn't tell you today whether the device is single-axis or dual-axis scrolling (in fact on Windows we may not really know).  Perhaps just using the has_precise_scrolling_deltas bool will be enough (dual-axis touchpads generally have it set to true while clicky mouse wheels are generally false as far as I remember).

2) We probably need to update blink and compositor scroll paths.  For the compositor path there may be extra work involved if the compositor doesn't already know the writing mode of the document.

Re #1: I'm not sure we can rely just on has_precise_scrolling_deltas. My synaptic touchpad is precise but, by default, has horizontal scrolling disabled. But maybe that's ok since these users might more frequently have horizontal scrolling enabled.

For 2, yes, that's why keyboard scrolls currently have to go to main - the compositor has no notion of writing modes.

Confirmed Trident/Edge works as expected for mouse wheels, though I don't have devices that can configure to 1 or 2 dimensions.

I'm not familiar with how blink can tell the document writing mode to compositor. Is it something I can help someway?

I believe we'd have to pass that information along as a new field on the GraphicsLayer. For everything but frames, the layers are created in CompositedLayerMapping (e.g. CompositedLayerMapping::UpdateScrollingLayers) while frames compositor layers are managed by PaintLayerCompositor. There's also some glue code in ScrollingCoordinator.

Given that we plan to eventually remove layers from the compositor, I'm not sure we should invest much effort here since it'll be throw-away. Perhaps the best bet is to work with paint team to ensure this is possible to do in SPv2 +pdr@

In any case, happy to help point you in the right place/provide reviews.

Gecko's idea to scroll horizontally when overflow is only horizontal looks reasonable to me, and would it make us easier too?
https://bugzilla.mozilla.org/show_bug.cgi?id=1358017#c1

We don't have to detect device capability nor writing-mode then, but still need to know whether overflow is single dimension or not. Does compositor have this information already?

Yeah, the compositor does know if a layer is scrollable in x or y. I like your generalization idea of scrolling whichever direction is possible, and I think it would be easy to implement. It does differ from OSX's native behavior though.

Note that the proposal here was to pay attention ONLY to the writing mode of the document.  So rather than plumb this through for every layer, perhaps it's just a bit on LayerTreeHost or something (but I suppose iframes could be a problem).

Anyway I think it would be reasonable for non-precise scrolling devices to scroll horizontally when the nearest ancestor scrolling layer doesn't support vertical scrolling at all.

Ideally this should be spec'd somewhere, but as long as someone files a spec issue I think it would be fine to proceed with implementation and not necessarily block on the spec. I don't think the specs today make any effort to connect the low-level input signals to details of scrolling (eg. direction inversion).

There's https://drafts.csswg.org/cssom-view/#scrolling-events but also https://w3c.github.io/uievents/#events-wheelevents
(Possibly the scroll event should be defined in ui-events.)

This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue.

Sorry for the inconvenience if the bug really should have been left as Available.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot