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

Issue 804164 link

Starred by 3 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression

Sign in to add a comment

Some combinations of CSS filters cause complete rendering failures

Reported by, Jan 21 2018

Issue description

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

Steps to reproduce the problem:
1. Go to
2. Edit the style on the root html element to read: "filter: invert(100%) hue-rotate(180deg) brightness(105%)"

What is the expected behavior?
All elements on the page are rendered as before, except with a luminance inversion and brightness adjustment.

What went wrong?
The entire page becomes blank white, with nothing visible.

Did this work before? Yes 64.0.3282.99

Does this work in other browsers? N/A

Chrome version: 66.0.3327.0  Channel: canary
OS Version: OS X 10.11.3
Flash Version: 

Note that deleting the brightness filter, so that the style reads "filter: invert(100%) hue-rotate(180deg)" results in expected behavior. It's the addition of the brightness filter to the list that triggers the bad rendering.

I have tested this on Chrome 64 and 66, but my users are reporting issues with Chrome 65, where I am guessing this was introduced.
Additional filter combinations:

* "filter: invert(100%) brightness(105%)" = works
* "filter: hue-rotate(180deg) brightness(105%)" = fails
* "filter: brightness(105%) contrast(85%)" = fails
* "filter: invert(100%) contrast(85%)" = works
* "filter: hue-rotate(180deg) contrast(85%)" = fails

And to include the original two filter sets from the original bug report for easy comparison:

* "filter: invert(100%) hue-rotate(180deg)" = works
* "filter: invert(100%) hue-rotate(180deg) brightness(105%)" = fails
In case there is some question about the purpose of applying CSS filters to the root element, or what an acceptable workaround might be: this is the crux of accessibility extensions like my own, Deluminate, and this poses a serious problem for my ability to adjust the brightness and contrast of sites through the extension.
Interesting addendum: while "filter: brightness(105%) contrast(85%)" fails, "filter: brightness(85%) contrast(85%)" works. So there's a distinction between brightness levels below 100% and above 100%.
One thing that makes this especially difficult is that there is some dependency I don't fully understand on the amount of detail on the page. A simple page containing very few elements can have more filters applied, whereas complex real-world pages like GitHub's develop frustratingly arbitrary rules like those I discovered above.
I have created a small test file that effectively triggers the issue on my Macbook. It was created by taking this issue page and paring it down. There are three key elements of this test file that trigger the issue:

* The set of CSS filters on the root html element. Disabling either of them causes the page to render correctly.
* The "position: fixed" style on the "feedback button." Disabling that style causes the page to render correctly.
* The length of the page. Deleting enough of the placeholder text so that the page does not need to scroll to view it all will cause the page to render correctly.
6.4 KB View Download
Labels: -Pri-2 Needs-Bisect M-65 Pri-1
Tested the issue on chrome reported version 66.0.3327.0 using Mac 10.12.6 with steps mentioned below:
1) Launched chrome reported version and dragged and dropped the test.html file provided in comment#5
2) Disabled CSS filters on the root html element from devtools style section didn't observer any change in the behaviour
3) Right click on feedback button on right bottom of page and clicked on inspect, disabled the style "position: fixed", didn't observerd any change in the behaviour
4) Selected some text, right clicked on it and clicked on inspect, on devtools element section right clickm on text area and clicked on Edit as HTML and deleted some text until no need of scroll bar, didn't observerd any change in the behaviour
As we don't have Mac 10.11.3 to test, we have tested it on 10.12.6

Please find the attched screen cast for your reference and let us know if we missed anything in reproducing the issue, if possible could you please provide the screencast of the excepted behaviour of the issue which helps us in further triaging it.

8.2 MB View Download
Labels: Triaged-ET Needs-Feedback Needs-Triage-M66
NextAction: 2018-02-05
You reproduced my steps accurately, but it's clear you did not experience the issue. I am attaching a video of what it looks like when I do the same thing. I will also try on another machine and operating system.
1.6 MB View Download
Project Member

Comment 11 by, Jan 22 2018

Labels: -Needs-Feedback
Thank you for providing more feedback. Adding requester "" to the cc list and removing "Needs-Feedback" label.

For more details visit - Your friendly Sheriffbot
I would also be curious about whether the original steps to reproduce I wrote up would reproduce the bug for you. I *have* found some finicky details of this bug, and I wouldn't be surprised if it doesn't behave exactly the same way on every system. Here is a video of the behavior I described in my initial post.
1.3 MB View Download
Components: -Blink>Compositing Internals>GPU
NextAction: ----
Given the behavior depends on the page complexity, and that it doesn't reproduce everywhere, I believe this is somehow related to graphics resources. Passing it on to those who might know more.
I have failed to reproduce this bug on another machine running Windows 7. I'd agree that this is likely to be related to graphics resources, so I'll share the hardware information of the system that experiences this problem:

MacBook Pro (Retina, 15-inch, Late 2013)
Processor: 2 GHz Intel Core i7
Memory: 16 GB 1600 MHz DDR3
Graphics: Intel Iris Pro 1536 MB

The machine that failed to reproduce it does not have a high DPI display, is running Windows 7, and has a GeForce GTX 970 with 4 GB memory, all of which may impact the available graphics resources.
Unable to repro this from ET end as mentioned in comment#7, hence forwarding this isssue to inhouse team to test this issue as per configuration mentioned in Comment#14, hence adding label as TE-NeedsTriageFromHYD, can anyone from inhouse team have a look at this issue.

Configuration where ET team have tested are as follows:
MacBook Air (13-inch, 2017)
Processor 1.8 GHz Intel Core i5
Memory 8 GB 1600 MHz DDR3
Graphics Intel HD Graphics 6000 1536 MB

Labels: TE-NeedsTriageFromHYD
Labels: TE-NeedsTriageFromMTV
Unable to reproduce the issue on mac 10.13 with high sierra (which is mentioned in C#14) & as per the steps mentioned in C#0,5 & 12 using chrome latest Canary-66.0.3331.0 and reported version-66.0.3327.0 .

Tested Mac configuration:
Mac book pro (Retina, Mid 2012)
Processor 2.3 GHz intel core i7
Memory 16 GB 1600MHZ DDR3
Startup Disk Macinthose HD
Graphics Intel HG Graphics 4000 1536MB

Please find the attached screencast for reference.As inhouse team do not have Mac 10.11.3 , could someone from MTV team please take a look (it may reproducible on this).


4.0 MB View Download
Labels: -TE-NeedsTriageFromHYD
Successfully reproduced this on

MacBook pro retina 15'' late 2013
Intel Iris Pro 1536 MB
Chrome 65.0.3325.146
OS X 10.11.6

Interestingly, if I force it to switch to discrete graphics (NVIDIA GeForce GT 750M 2048 MB) the issue immediately disappears
Labels: Needs-Triage-M65
Adding "Needs-Triage-M65" per comment #19.

Comment 21 Deleted

Comment 22 by, Mar 27 2018

All the people who reported about the problem had MacOS 10.11 and build-in Intel video cards.
Status: Assigned (was: Unconfirmed)
ccameron@, can you take a look? It seems like we fail as soon as color matrix filter is in the chain.
I wasn't able to reproduce this on my Macbook Pro with an Intel GPU (or with an NV GPU) on Stable on Canary (but I have 10.13).

Please navigate to about:gpu, print the page as a PDF, and attach that.
here you go
136 KB Download
Tried also with GPU raster disabled, and it doesn't reproduce.

Does this reproduce when you run with --disable-gpu?

This might be a driver bug in 10.11 -- is there a reason your OS isn't being updated?
With this flag everything works. My OS refuses to update due to a minor SSD SMART error which is there for 4 years without any issues.
I just found out that my SSD SMART error disappeared (is this even possible?) and I could successfully update to macOS 10.13.4. After updating this issue disappeared to it's definitely tied to OS version.
I've had this happen to me while using on occasion

By chance I was curious to see if restarting Chrome resolved the issue, and it did the no longer persisted. I suspect after long uptime's the issue will resurface.

Good bug hunting, all!

chrome://gpu :

Version Information
Data exported	2018-04-09T02:06:03.705Z
Chrome version	Chrome/65.0.3325.181
Operating system	Mac OS X 10.13.1
Software rendering list URL
Driver bug list URL
ANGLE commit id	2c9cc8b6e810
2D graphics backend	Skia/65 8a3e0b31927ae78bc3e9c342b1290a6a64233674-
Command Line	/Applications/Google Chrome --flag-switches-begin --enable-devtools-experiments --enable-experimental-canvas-features --enable-tab-audio-muting --enable-experimental-extension-apis --flag-switches-end
Driver Information
Initialization time	87
In-process GPU	false
Passthrough Command Decoder	false
Direct Composition	false
Supports overlays	false
Sandboxed	true
GPU0	VENDOR = 0x10de, DEVICE= 0x0fd5
GPU1	VENDOR = 0x8086, DEVICE= 0x0166 *ACTIVE*
Optimus	true
Optimus	true
AMD switchable	false
Driver vendor	
Driver version	10.28.29
Driver date	
Pixel shader version	4.10
Vertex shader version	4.10
Max. MSAA samples	8
Machine model name	MacBookPro
Machine model version	10.1
GL_VENDOR	Intel Inc.
GL_RENDERER	Intel HD Graphics 4000 OpenGL Engine
GL_VERSION	4.1 INTEL-10.28.29

Sign in to add a comment