Able to reproduce this issue on reported version 63.0.3239.84 and on latest canary 65.0.3309.0 using Mac 10.13.1.

Observations: Issue is not seen in Firefox and Safari. Issue is not seen in Linux and Windows

This issue is seen from M53. Till M52 tab crash is seen on navigating to https://codepen.io/cssence/pen/mpmMMO.  Hence considering this issue as Non-Regression from M53 and marking as Untriaged.

Thanks!        

I was able to repro on Windows with a high-DPI monitor and then on Linux using --enable-prefer-compositing-to-lcd-text so this is about compositing rather than Mac specific.

Selecting the text causes it to be painted so it seems we're not invalidating correctly.

Confirmed this only happens with impl-side scrolling.

I don't think it is an invalidation issue though, because the whole point of impl-side scrolling is to paint the whole scrolled contents so that repaint is not needed when scrolled.

It seems to me that we have a compositing recorder (for isolating blending descendants) that is clipped inadvertently.

Do we have a bisect for this?

The problematic code here:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp?rcl=2485344d4e8792bc4f9716deadda41fbc0d89ad9&l=435

IMO passing a layer bound to canvas->saveLayer() is a premature-optimization that created more problems than it helped.

1. The minimal layer bound is needed is the intersection of the inherited clip rect and the union of descendant rects. The inherited clip rect can be always inferred from the canvas context (current device clip region), and in this bug, we passed a rect that is inadvertently clipped by the fragment background rect when it shouldn't.

2. The union of descendant rects is expensive and error-prone to compute at paint time. In the past we have to compute it early because canvas commands are executed on the fly, but now we always record them into a paint record for replay later. We can easily compute the union during post-processing.

Another problem with the code is that we really shouldn't apply any compositing recorder on the scrolling content layer, because any stacking context effect happens at a higher hierarchy. This also revealed another design bug in impl-side scrolling that the creation of scrolling content layer created an isolated group as a side effect. If we also created a background layer due to non-local attachment, blending children will be isolated incorrectly (without the background).

The bad clip problem can be easily solved by skipping the compositing recorder on scrolling content layers. However the mix-blend-mode will still not work properly, and is very difficult to fix until SPv2.

Fix pending: https://chromium-review.googlesource.com/c/chromium/src/+/868740

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

commit 6689b3106a060b5464397144503d19da2ddad78d
Author: Tien-Ren Chen <trchen@chromium.org>
Date: Tue Jan 23 01:49:05 2018

[Blink/Paint] Should not apply compositing recorder to scrolling layers

Any stacking context effects should have been applied by layers at a
higher hierarchy already. Applying the additional compositing recorder
will clip descendants inadvertently.

BUG= 798148 

Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2
Change-Id: I4eddaf12baa61f48e38b01fa4c15097a8765a9d3
Reviewed-on: https://chromium-review.googlesource.com/868740
Commit-Queue: Tien-Ren Chen <trchen@chromium.org>
Reviewed-by: Xianzhu Wang <wangxianzhu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#531123}
[add] https://crrev.com/6689b3106a060b5464397144503d19da2ddad78d/third_party/WebKit/LayoutTests/compositing/overflow/scrolling-content-layer-should-not-be-clipped-expected.html
[add] https://crrev.com/6689b3106a060b5464397144503d19da2ddad78d/third_party/WebKit/LayoutTests/compositing/overflow/scrolling-content-layer-should-not-be-clipped.html
[modify] https://crrev.com/6689b3106a060b5464397144503d19da2ddad78d/third_party/WebKit/Source/core/paint/PaintLayerPainter.cpp