Please assign to bokan@chromium.org :)

Hey bokan@chromium.org, I don't mean to bother you, but wondering if you'd guess this other test case not allowing horizontal scrolling in a fixed scrolling element fitting the viewport, has the same cause as this issue.

-> https://output.jsbin.com/rutoceb/quiet

Open it in safari, see how using a horizontally scrolling gesture on the full screen red element behaves as normal, scrolling content left and right. In chromium, no scrolling is afforded from the same input. If I change the right property to -1px on the 'root' element, then the red block doesn't perfectly match the viewport (initial containing block?) and everything behaves as expected.

If it's a different cause, I'm happy to file a separate issue. Thanks for your time.

Yes, I believe it's the same issue. It's related to the "Implicit Root Scroller" feature - until recently that was gated by chrome://flags/#enable-experimental-web-platform-features. I've recently enabled it in Canary (temporarily) for testing. I'll be turning it off shortly but I'll fix this issue before I ship it out to stable channel.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/59d9ba119448a269289d57e7c3d23a7f04f19248

commit 59d9ba119448a269289d57e7c3d23a7f04f19248
Author: David Bokan <bokan@chromium.org>
Date: Tue Nov 27 19:17:33 2018

[root-scroller] Don't promote when ancestor is scrollable

If we have a candidate implicit root scroller, we should only promote it
if it doesn't have a scrollable ancestor. The reason for this is that we
end scroll chaining at the root scroller. This is necessary as the root
scroller consumes all scroll in the form of overscroll effects. A (user)
scrollable ancestor would be broken in this case, as shown in the
example on the attached bug.

Note: overflow in an ancestor is still allowed, as long as its overflow
style is hidden or visible.

Bug:  837007 
Change-Id: Ied7a9f02eab76c4ea59fced94d0804ba47ef4e4a
Reviewed-on: https://chromium-review.googlesource.com/c/1351590
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#611245}
[modify] https://crrev.com/59d9ba119448a269289d57e7c3d23a7f04f19248/third_party/blink/renderer/core/page/scrolling/root_scroller_controller.cc
[modify] https://crrev.com/59d9ba119448a269289d57e7c3d23a7f04f19248/third_party/blink/renderer/core/page/scrolling/root_scroller_test.cc

Hey bokan@chromium.org, with your fix enabled, would you mind testing this url again...

https://output.jsbin.com/rutoceb/quiet

Not for the horizontal scrolling of the viewport covering scroll container...

But for the little white rectangles that rest on the bottom edge of the screen. I ask, because the bug that it exhibits is only happening in the jsbin output endpoint, and not in the editor endpoint (https://jsbin.com/rutoceb/edit) which has the scrollers obviously not on the edge of the window. And if it isn't fixed by your changes, I will file it as a possible issue with the implementation of overscroll-behavior.

Steps are...
1. Hover mouse on any white rectangle.
2. Attempt to scroll vertically.
3. Notice nothing scrolls, white rectangles do not scroll into view.
4. Move mouse a few pixels above white rectangles top edges, into the area which is not a horizontal scroll container.
5. Attempt vertical scroll and see how white rectangles scroll into view.
6. Again try to scroll vertically from white rectangles, nothing happens to scroll them away, until hovering area a few pixels above.

Once more, this bug is only seen in this full screen (windows edge) scroll container ui, not in the editable link from the text.

Just checked - I believe it's unrelated to this bug or the ImplicitRootScroller feature more generally (you can try disabling/enabling using --disable-blink-features=ImplicitRootScroller or --enable-blink-features=ImplicitRootScroller).

I was, however, able to make it work when using a low-DPI configuration (e.g. --force-device-scale-factor=1). I can reproduce your issue when using (default, on my system) high DPI (--force-device-scale-factor=2). I'll continue to investigate where the problem is - in the mean time, would you mind filing a new bug? Thanks

Ok, found the problem and filed bug 909083. FYI: this is a bug in how we handle pointer-events: none. If you remove it from the .tray element everything works.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/eb070d8200bc92b44e939751833273617194c947

commit eb070d8200bc92b44e939751833273617194c947
Author: David Bokan <bokan@chromium.org>
Date: Fri Dec 07 14:04:30 2018

[root-scroller] Allow horizontal document scrolling

In https://crrev.com/59d9ba119448a269289d57e7c3d23a7f04f19248 we added
the restriction that an element can only be promoted to implicit root
scroller if none of its ancestors have scrolling or clipping.

This inadvertantly removed a special case for allowing a horizontally
scrollable document.

Bug:  837007 
Change-Id: I5a52d821266a5775e5be8641bdb6ed56fc9892f3
Reviewed-on: https://chromium-review.googlesource.com/c/1366784
Reviewed-by: Dave Tapuska <dtapuska@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#614688}
[modify] https://crrev.com/eb070d8200bc92b44e939751833273617194c947/third_party/blink/renderer/core/page/scrolling/root_scroller_controller.cc
[modify] https://crrev.com/eb070d8200bc92b44e939751833273617194c947/third_party/blink/renderer/core/page/scrolling/root_scroller_test.cc