Looks like a nested composited (non-iframe) scroller (at least on windows - where we don't use overlay scrollbars so they show up) but the scrollbars are missing. Could be related to being chromeos, or a touchscreen, depending what the logic is.

There's login credentials in the sample web page link in #0.

Although I don't currently have permission to view the videos in the Drive links, this sounds identical to the issue that we reported to Google support on September 19.  In our school's student information system our teachers lost the ability to scroll left and right in their gradebooks using a Chromebook touchpad.  The horizontal scrollbar still appears and works as expected in Internet Explorer, Firefox, and Chrome for Windows; Chrome OS 59; and Chrome and Safari for Mac.

+flackr@ for triage.

Hi flackr@, polite ping on this issue

Hi,

Do we have any updates on this issue?

Thanks!

It looks to me like the overlay scrollbars are being covered up. The element with class .cover-container sets overflow: auto; with the next sibling element .table-container (also positioned and hence on top) trying to size to the content size. Since there's no space actually reserved for the overlay scrollbars they get covered up.

If you change .cover-container to be on top (e.g. by setting z-index: 1) the overlay scrollbars do become visible and you can use the right one to drag and scroll. However, this means that you can no longer target the content in .table-container as it is below the cover container.

While this is no longer working - this does seem like the expected behavior with overlay scrollbars when you try to create your own fake scroller with overflow-hidden on top of it :(.

flackr@'s analysis is correct. This also affects Chrome Mac's overlay scrollbars in the same way for the same reason (when composited - due to a Retina screen, low-res works). These kinds of "fake-scrollers" tend to be problematic for overlay scrollbars. The new CSS scrollbar-gutter property should help here but I don't think it's implemented anywhere yet (https://www.w3.org/TR/css-overflow-4/#scollbar-gutter-property).

Interestingly, it kind of works in Safari, you can see the scrollbars but you can't click on them. Overlay scrollbars and paint order is unfortunately not well specified (see issue 758351); interop issues and bugs abound. Even within Safari, there's differences based on whether the scroller is composited or not.

Here's a test page I put together: http://output.jsbin.com/liqibixuro demonstrating the issue. On a low res screen - the top box will be composited, bottom non-composited. The case on ixl.com is basically the "abs: before" box.

Unfortunately these issues here are deep and complicated. The slimming paint project will be looking at how to handle scrollbars soon so we should make sure to consider these kinds of cases. 

For users who are deeply impacted by this I would suggest turning off overlay scrollbars in chrome://flags/#overlay-scrollbars

We are still seeing the same issue even with the latest version of Canary.  Here is a link with a video of the behavior.

https://drive.google.com/file/d/1zPuKIrrcuVxSYfcbGX226Bdjvne-V3JB/view?usp=sharing

Removing Internals>Compositing since this is a generic overlay scrollbar issue.

Issue still persists on Chrome OS 68.0.3440.34. Are there any updates on this?

Hello!
This bug is receiving this notice because there has been no acknowledgment of its existence in quite a bit of time
- If you are currently working on this bug, please provide an update.
- If you are currently affected by this bug, please update with your current symptoms and relevant logs.

If there has been no updates provided by EOD Wednesday, 12/19/18 (5pm EST), this bug will be archived and can be re-opened at any time deemed necessary.

Thank you!

Due to lack of action this bug has been Archived. If work is still being done on this issue or you are still experiencing this issue please feel free to re-open with the appropriate information.

I'm not sure this should be closed. It may not be a priority to fix over other bugs but we should track it. David, could you triage this?

Took another look today. I believe Chrome's behavior here is technically correct now. In the case of the ixl.com URL, what we have is table that's technically unscrollable (overflow: hidden). It captures wheel events and changes the scroll position. To display scrollbars, the page keeps a dummy scroller behind the table that has the same proportions as the table and has it's scroll linked via JS. With non-overlay scrollbars, this box is larger than the table by the size of the scrollbar. Effectively:

<div id="dummyScroller" style="position: absolute; overflow: auto>
  <div id="dummyContent"></div>
</div>
<table id="content" style="position: relative; overflow: hidden>
</table>

So now with overlay scrollbars, these two boxes are the same size. The table paints on top of the dummy so we don't see the scrollbars. If you add opacity to the table, you'll see the scrollbars are indeed appearing.

I've updated my reduction in #10: https://output.jsbin.com/puhopid. There's one difference we now have with Safari, that's the third box - the one that emulates this case. Chrome draws the "pos: rel after" orange box on top of the scrollbar, Safari paints it below. Not sure which is correct.

pdr@: do you know who's correct in terms of paint spec?

I suspect Chrome is actually correct here since switching Mac scrollbars to "always on" makes them paint behind the "pos: rel after" box. Even in Safari, the scrollbar paints on top but clicking on it actually targets the box underneath. If that's the case, then I'm not sure there's much to be done here on Chrome's side from an eng perspective. This is overlay scrollbars working as intended. Either apps like this need to be updated or Chrome UX needs to redesign the interaction model.

Re#11: In this video, while they're subtle, I can see the scrollbars do appear when you two finger scroll so that's working as intended. When they appear, are you able to click and drag them? If you move your mouse near the edge where they appear when scrolling, do the scrollbars appear?

Painting the pos: rel after element on top of the scrollbar is the correct behavior.

I'm not sure that the spec says anything about scrollbars and when they should
be painted, but for sure the scrollbar of a positioned scroller should be painted before the next positioned element in paint order.

Hi All,

Based on discussions I've had with bokan@ as well as PMs of the Chrome UX team, the next best course of action is to reach out to the site developers for a permanent fix because (as stated in earlier comments) this isn't just affecting Chrome's scrollbars, but Macs are also struggling with it.

I'll go ahead and close this bug out but if this issue starts to expand to other sites please feel free to provide an update.

Thank you!