Cloudless Chrome - Broken CSS filters

First published: Read time: 5 mins

A month or so ago I happened to open this very website in the latest version of Chrome (65 at the time) and I noticed something was a little bit off. The animating clouds in the header of the website were very broken. Considering the code for this part of the site hasn’t changed since I first built it, this pointed to the fact that this change hadn’t come from me.

As you can see in the images below, there was quite a rendering difference between Firefox and Chrome.

Example of the clouds in Firefox browser
Animated SVG clouds with a slight blur in Firefox.
Example of the broken clouds in Chrome browser
There are supposed to be some clouds here, but Chrome is having issues.

What happened?

Well as you may (or may not) know all modern web browsers are what is known as “evergreen browsers”. This is defined as:

…browsers that are automatically upgraded to future versions, rather than being updated by distribution of new versions from the manufacturer, as was the case with older browsers.

So the Chrome browser had automatically updated and in doing so a regression had been introduced. Unfortunately this is one negative point around auto-updating browsers that require no user interaction. The update will happen, something will break and the user will have no idea what changed. Luckily this doesn’t happen very often as browser vendors have a very extensive testing process before a new version hits the stable channel. It takes approximately 10 weeks from a commit entering the Canary channel to land on the stable channel. You can see what the Chrome team have in the pipeline on the ChromeStatus website.

CSS filter broke the clouds

So what actually broke? It turned out a single line of CSS was causing the issue:

.cloud-class-example {
  //...
  filter: blur(2.2px)
  //...
}

Applying the blur() CSS filter to the cloud SVG was breaking the rendering. After a little investigation it turns out that applying any CSS filter seemed to break the rendering, it wasn’t just tied to blur().

Looking through the Chromium bugs for anything related to “CSS filter”, two bugs are listed that looked to be very similar to the issues I’ve been seeing:

Reading through these bug reports it turns out that this bug is very specific to OSX version 10.11 with Intel video cards. So only a certain number of users will be seeing this issue. Checking my computer specifications, sure enough 10.11 with an Intel video card!

Examples

For those wondering if you’re affected by this bug I’ve created a very basic test page that can be viewed on Sassmeister (Gist).

Here’s a screenshot from Firefox of what the rendering should look like:

Firefox rendering the example
Firefox browser renders the example as expected.

Compare it to how it renders in Chrome 66. Very broken!

Chrome rendering the example
Chrome 66 looks really broken, with some clouds not even being rendered.

In the example code you will see I tried a number of permutations to see if it was a combination of the animation and the filter, or if it was only a SVG rendering issue related to the filter. It turns out that it has nothing to do with the animation or SVG’s. The clouds are still broken on non-animated assets and non-SVG content (<div>).

Solution

So what’s the solution for this issue you may ask? Well aside from upgrading your OS from OSX 10.11 or removing the CSS filtering from the element, there really isn’t a solution to this issue at the moment. Oh no! you may shout. But do not despair, the Google Chrome team have it covered. You will be pleased to hear that in the latest Chrome Canary (68 at the time of writing) all the examples render fine!

The list of browsers with this specific bug for OSX 10.11 with Intel GPU’s are:

  • Chrome 64 - not broken
  • Chrome 65 - broken
  • Chrome 66 - broken (current stable channel)
  • Chrome 67 - broken (current beta channel)
  • Chrome 68 - not broken (current Canary channel)

Chrome 68 has a planned release date of July 2018. This is when it should hit the stable channel, at which point I expect this issue to rectify itself very quickly for the small number of users it affects.

Conclusion

Todays “evergreen browsers” will auto-update without the need for any user interaction and in doing so this can sometimes introduce regressions. The average user won’t understand the origin of this regression since it will look like nothing has changed.

Is this a bad? Sure it could be! But if you compare it to the web when we didn’t have “evergreen browsers” and we relied on users or admins to update the browser version (IE8 anyone?), we are in a much better place now. New features and bug fixes are rolled out quickly, meaning a safer and more exciting web for users and developers alike!

You will be pleased to hear that all major browser vendors now have auto-updating browsers (even Microsoft Edge!).

Webmentions