Confirmed on 57.0.2987.133/Linux

Also in M58 linux. When the mouse-down happens on the scroll bar for the right element we repaint the left list to blank, then paint it properly again when the mouse up happens after scrolling.

Removing will-change: transform on the left scroller makes the issue disappear, so this is a compositing issue.

A bisect is required.

Mouse-up/mouse-down is not required. Just dragging without lifting the mouse reveals the issue.

In the left pane, React is adding and removing list elements (divs) at absolute positions with top set to position the element at the correct location within the scrolling layer. At any given time, only the divs for the visible region of the scroller are in the DOM.

When the right pane scroll begins moving, we repaint the left pane incorrectly, while scrolling we do not repaint the left frame (we shouldn't) and when scrolling stops we repaint again and get the correct content.

If you scroll the left pane just a little, you can see that we do paint content that is visible with 0 scroll offset, as if it were positioned with 0 scroll offset. But we do not repaint content that is visible only at the current scroll position. This makes me think that the compositor code is at fault here, always compositing the scroll offset 0 content during the mouse move.

I'll dig some more trying to see what the JS/CSS does when the scroll is happening, as there are definitely some dynamic changes.

schenney@, assigning to you while you investigate.

OK, I have a bisect on Linux.

I found 399529 is a good version and 425230 is bad version. Bisect points to this set:
https://chromium.googlesource.com/chromium/src/+log/d50f0b14f31a77d7c18296dde00e54a07687d06b..49cbf7dc7508bec4920ed325afa0b57749795ac1

schenney@: could you take a look at the above list? Could it be:

Raster display item lists via a visual rect RTree. by wkorman

Nothing jumps out. It might be the rtree though.

I'll double check, and try to get a per-commit bisect.

The rtree patch does indeed seem to be to blame, although I have no idea why it would. I don't think this is a P1. Though the content disappears while scrolling, it does reappear promptly and functionality is not lost (you can't do anything in one pane while scrolling another). 

I don't expect to get to this soon, unassigning self in case others able to look.

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

Works now, it seems. Closing.