Issue 824395 has been merged into this issue.

We are getting many reports internally, so would be great to have a fix for next Dev release scheduled - Monday- 03/26.

+1 to have fix available for next week Dev. 

chrishtr@, would reverting the patch be worse than leaving it in? Put another way, reverting for a while to fix the issue would relieve the pressure to fix it quickly, given the other issues we're facing with SVG stacking context.

It occurs to me that someone could run this in a Debug build and see what asserts. I suspect something will.

I will investigate and try to fix today.

I can't reproduce this yet. I loaded chat.google.com and scrolled around in various
forums. Please comment if you have a specific sequence that reproduces.

For me, it reproduces when expanding long chat threads by clicking the
circle showing the number of hidden messages on the left side of the
thread. The expanded messages have invisible user names and profile photos,
and sometimes the message text overlaps or jumps around.

@sunnyps can you send me a screenshot of broken content?

I can now reproduce the bug.

The root cause is I think  crbug.com/646437 . The transformed ancestor is
 supposed to always be the same. Debugging now with trchen.

this bug no longer reproduces in 67.0.3379.0 (Official Build) canary (64-bit) (cohort: Clang-64) but there is another regression on chat.google.com which I have filed as  issue 825928 .

I still see it in Canary  67.0.3379.0 on Windows. Experiment related? We do have a Finch trial running for Root Layer Scrollng and Slimming Paint v1.75.

I might redo the bisect, however.

You don't need to do a bisect. I have a fix in code review.

https://chromium-review.googlesource.com/c/chromium/src/+/979169

 Issue 825928  has been merged into this issue.

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

commit 5fa574e760ef526149e29940e01f5a8483009748
Author: Chris Harrelson <chrishtr@chromium.org>
Date: Tue Mar 27 00:47:00 2018

[RLS] Fix transform ancestor for squashing layers.

Previously, there was an assumption that the transform ancestor of the compositing
container matched that of the squashed layer. This is wrong in the situation that
the compositing container has a transform.

Previously there was a check in the squashing code to skip some offsets if the
compositing container has a transform. This code was brittle, and started failing
once code was changed to omit composited scrolling offset from the compositing container.

Bug:  824811 , 646437 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: Ia11af0d954065b31d38d61f8d4561ee3edd57e41
Reviewed-on: https://chromium-review.googlesource.com/979169
Reviewed-by: Tien-Ren Chen <trchen@chromium.org>
Commit-Queue: Chris Harrelson <chrishtr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#545909}
[modify] https://crrev.com/5fa574e760ef526149e29940e01f5a8483009748/third_party/WebKit/Source/core/paint/PaintLayer.cpp
[modify] https://crrev.com/5fa574e760ef526149e29940e01f5a8483009748/third_party/WebKit/Source/core/paint/PaintLayer.h
[modify] https://crrev.com/5fa574e760ef526149e29940e01f5a8483009748/third_party/WebKit/Source/core/paint/PaintLayerTest.cpp
[modify] https://crrev.com/5fa574e760ef526149e29940e01f5a8483009748/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMapping.cpp
[modify] https://crrev.com/5fa574e760ef526149e29940e01f5a8483009748/third_party/WebKit/Source/core/paint/compositing/CompositedLayerMappingTest.cpp