New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 3 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Jan 2018
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 2
Type: Bug

Sign in to add a comment

Issue 798148: In combination with mix-blend-mode, elements in overflow:scroll area are cut off/invisible

Reported by, Dec 30 2017

Issue description

UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36

Example URL:

Steps to reproduce the problem:
1. Open Chrome on Mac
2. Launch
3. Scroll down inside the dashed area
4. Additional text is cut off and can't be read

What is the expected behavior?
Text that is scrolled into view is being displayed properly, as it is in Chrome on Windows. On Mac, currently text remains invisible, although width and especially height of the overflow area are correct.

What went wrong?
A DOM child element inside the scrollable container has mix-blend-mode applied, that seems to cause the issue.

Does it occur on multiple sites: N/A

Is it a problem with a plugin? No 

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 63.0.3239.84  Channel: stable
OS Version: OS X 10.12.6
Flash Version: 

Chrome on Windows: OK
Firefox: OK
Safari: OK

Comment 1 by, Dec 31 2017

Labels: Needs-Triage-M63

Comment 2 by, Jan 1 2018

Components: Blink>Scroll
Labels: -Type-Compat M-65 Triaged-ET Type-Bug
Status: Untriaged (was: Unconfirmed)
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  Hence considering this issue as Non-Regression from M53 and marking as Untriaged.


Comment 3 by, Jan 4 2018

Components: -Blink>Scroll Blink>Paint>Invalidation
Labels: OS-Linux OS-Windows
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.

Comment 4 by, Jan 16 2018

Status: Available (was: Untriaged)

Comment 5 by, Jan 16 2018

Components: -Blink>Paint>Invalidation Blink>Paint
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?

Comment 6 by, Jan 16 2018

The problematic code here:

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.

Comment 7 by, Jan 17 2018

Status: Started (was: Available)
Fix pending:

Comment 8 by, Jan 23 2018

Project Member
The following revision refers to this bug:

commit 6689b3106a060b5464397144503d19da2ddad78d
Author: Tien-Ren Chen <>
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
Commit-Queue: Tien-Ren Chen <>
Reviewed-by: Xianzhu Wang <>
Cr-Commit-Position: refs/heads/master@{#531123}

Comment 9 by, Jan 23 2018

Status: Fixed (was: Started)

Sign in to add a comment