New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
This site will be read-only for 3-4 hours starting at Sunday, 08:00AM PDT
Starred by 268 users

Comments by non-members will not trigger notification emails to users who starred this issue.

Issue metadata

Status: Available
Owner: ----
EstimatedDays: ----
NextAction: 2017-07-01
OS: All
Pri: 2
Type: Feature

Sign in to add a comment

Implement backdrop-filter from Filter Effects Module Level 2

Reported by, Jun 7 2015 Back to list

Issue description

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

Example URL:,css,output

Steps to reproduce the problem:
1. Visit,css,output
2. The box's background should be a blurred version of its backdrop
3. Adjusting the sliders should change the effect

What is the expected behavior?
The box has a background of a blurred version of its backdrop.

What went wrong?
The backdrop-filter property isn't supported, so nothing.

Does it occur on multiple sites: Yes

Is it a problem with a plugin? No 

Did this work before? No 

Does this work in other browsers? No Everything that isn't webkit admittedly everything

Chrome version: 45.0.2421.0  Channel: canary
OS Version: OS X 10.10.3
Flash Version: Shockwave Flash 18.0 r0

This has already been implemented in Webkit nightlies (although a few months later and its still in the nightlies). Could this be implemented in Chromium nightlies as well?
Labels: -OS-Mac OS-All M-45 Cr-Blink-CSS-Filters
Status: Untriaged
Able to reproduce the issue on Windows 7, Ubuntu 14.04 and MacBook Air 10.10.3 using Google Chrome stable - 43.0.2357.81 and canary - 45.0.2424.0 versions by following steps mentioned below.

1. Navigated chrome to,css,output
2. Adjusted the blur slider
3. Observed that blur filter effect is not seen on background

This is a non-regression issue seen from past M20 -  20.0.1086.0 version, Hence marking it as untriaged.
Requesting Dev team to look in to it.


Comment 2 by, Jul 10 2015

Labels: -Cr-Content

Comment 3 by, Aug 10 2015

Just were reading this on this worth second look and probably easy to port existing WebKit implementation?

Comment 4 by, Aug 13 2015

Labels: -M-45
Status: Assigned
Also, will need to be fixed in order to allow for backdrop filters to cross intermediate render surfaces in the compositor.

Comment 5 by, Aug 13 2015

Labels: -Type-Bug Type-Feature

Comment 7 by, Aug 13 2015

Blockedon: chromium:314867
Blockedon: chromium:432157
Blockedon: chromium:521815
Project Member

Comment 10 by, Aug 21 2015

The following revision refers to this bug:

commit c266f7bac110aebada963292e67c51fd3195bb9a
Author: hendrikw <>
Date: Fri Aug 21 23:41:34 2015

cc: Allow transparent layers with background filters to render

If we have a background filter, we still need to render the fully
transparent stuff since the filter will still change what's beneath it.



Review URL:

Cr-Commit-Position: refs/heads/master@{#344912}


Blockedon: chromium:524689
Blockedon: chromium:525099
Project Member

Comment 13 by, Aug 27 2015

The following revision refers to this bug:

commit 18d1a7f3ba1f94a877d76d57cb8743143719eb8b
Author: hendrikw <>
Date: Thu Aug 27 04:49:43 2015

cc: Allow background filters on renderpasses with transparent background

This is needed to make backdrop filters mostly work.

Logged to capture
any possible issues that may come up related to this.


Review URL:

Cr-Commit-Position: refs/heads/master@{#345797}


Project Member

Comment 14 by, Aug 27 2015

The following revision refers to this bug:

r201314 | | 2015-08-27T14:13:26.412239Z

Changed paths:

blink: Add backdrop-filter support


Review URL:
Excellent! It is working!

For webdevs: It needs to be enabled by chrome://flags/#enable-experimental-web-platform-features and when would be finalized, this will be enabled by default for all. 

Comment 16 by, Aug 28 2015

Status: Fixed
Thanks for confirming ebraminio!
Well... mostly working.

There's still a few things that need to be fixed.
Status: Assigned
Reopening until the blockers are addressed so that I have a single place to track progress, thanks.

Comment 19 Deleted

Try Beta or Canary version, it definitely should be in Canary when the flag is enabled.

Comment 21 Deleted

Comment 22 Deleted

With #enable-experimental-web-platform-features enabled, it doesn't seem to work on OS X Yosemite, Google Chrome Canary 47.0.2505.0 (64-bit).

If you're using the demo mentioned above, make sure you change "-webkit-backdrop-filter" to "backdrop-filter" when testing.
UPDATE: It works on my phone, Im using Chromium 47

Comment 26 by Deleted ...@, Nov 27 2015

I really wish this to be implemented in the stable version. Is there any ETA?
This is pretty buggy when there are things animating over the element that has the blur applied to it. It seems to be redrawing a different kind of blur within all the child elements that have moved. 

Here's a video of something I'm playing around with that shows what I mean: The entire top area has a carousel and the element I'm hovering over gets some transforms and translate3ds applied to it..

Also if the element has a box-shadow, the backdrop blur is also blurring out what's behind the shadow instead of staying within the bounds of the element.
Re: #28: could you log a new bug for that? Also, it would be great if you could create a minimap repro case. It's hard to diagnose from a video.

Comment 31 Deleted

Comment 32 by, Dec 13 2015

It's not working for me at all. I'm in Linux in Chromium 47.0.2526.80 (64-bit) with the experimental flag turned on. I see black boxes like this:

Comment 33 by, Dec 13 2015

The demo uses -webkit-backdrop-filter, but Chrome supports the standard variation (just backdrop-filter), I believe. Have you manually changed it?
If you have, file a new issue about it (it would be good to go to chrome://gpu, save the report and attach it to the new issue).

Bear in mind that you are using Chromium, so it might be a distribution specific thing as well. :( Have you tried Google Chrome?

Comment 34 by, Dec 15 2015

@phistuck Yep, I modified all `-webkit-backdrop-filter` to `backdrop-filter`, in both Chrome and Chromium. Making a new issue for it:

Comment 35 by, Dec 15 2015

Are backdro-filters expected to work with transform:matrix3d? For example, if I have this content, with a DIV on top of it causing blur:

can we apply a rotation to the DIV and blur will still work, like this:


Comment 36 by, Dec 15 2015

In the second image, assume there's also CSS perspective applied.
Blockedon: chromium:570040
This is a spectacular feature, that makes possible some stunning designs, therefore I hope the implementation will be hardened a bit. Some informal feedback:

- As mentioned above here already by another user, when an element has backdrop filter and a box-shadow, the backdrop filter is also applied to the box-shadow area, which is incorrect. Webkit on iOS does not do this.

- I'm experiencing some buggy behavior wrt scrolling. The situation is a header bar that lies on top of a background image, where the header bar has a backdrop filter: blur applied. When I scroll with my mouse wheel, there is this flashing square in the top left corner, as if there is some redrawing issue. Strangely, when scrolling by dragging the scroll bar down, this issue does not occur.

- This next one I am not sure about, whether it is a feature or a bug. Imagine you have a fixed bar of 960px by 100px. this bar lies on top of a 960px by 600px image. The fixed bar has a blur backdrop filter applied. Imagine that the image is overall a deep blue. However, the background of the overall web page is white. What I am experiencing is that the edges of the header bar have a blurred white tone. What I was expecting is for the backdrop filter to only blur the underlying element, the image, however, it also seems to blur the webpage as a whole, hence the white creeping into the corners of the element. It seems the effect is not contained, if that makes sense.

Comment 39 Deleted

Comment 40 by, Jan 18 2016

Please, make sure all of the issues are filed separately (obviously, do not duplicate existing separate issues). You can comment here with all of the issue numbers so we could mark them as blocking this.
@ferdy, point 3 seems to be a feature. It works like that in OS X Yosemite. It should blur anything that's beneath it.
@beni: But in my interpretation, the white of the page background is not underneath it, it is underneath it in terms of layers (Z), but it sits on the side of the blurred element. I would not expect it to creep in like that, it makes a very common use case look quite ugly. Anyway, if this is as intended, so be it :) 
@ferdy I too think that the behavior is incorrect. It essentially samples the pixels for blurring outside of the element's borders. It makes sense at the implementation level, but I don't think that is the desired/expected effect. 
@beni: thank you, at least I'm not alone in thinking this :)
@ferdy I think you're right afterall. This does work differently in Safari right now.

I've been playing around with this in Safari and Chrome Canary and there do appear to be some differences. I've put this test online:

The first difference is when you disable the animation. For some reason it works the same as in Safari when animated, but differently when standing still. When it's still it has some white "bleeding" into it.

The 2nd difference I notice is that it doesn't work together with mix-blend-mode. This does work in Safari. (see screenshot)
1.3 MB View Download
Folks, all of your comments and reports are appreciated. However, it's much easier for the Chrome team if each issue is reported as a separate bug, with its own repro steps and reduced test case. That way, they can be triaged, tracked and fixed separately. Thanks!
@senorblanco. You are right, and sorry for the informal level of feedback. I just want to say that isolating these issues into a reproducible test case and properly reporting them costs a lot of time, which I do not have. It's not an excuse, just an explanation.
Did something happen to this feature? None of the demos work anymore for me.

Comment 49 by, May 16 2016

@ferdy:  `-webkit-backdrop-filter` no longer works, but `backdrop-filter` does (assuming you've enabled #enable-experimental-web-platform-features)
@ashley: I do have experimental web platform features enabled, and still it never works for me in Chrome, where before it did, regardless of which of the two properties I use. It's not working at all in any of the public codepens either. 

Example codepen:

If I remove the -webkit- prefix from the property there, the whole thing just turns black. Are you getting the same results as me?
ferdy.christant: could you open a new bug for this regression, and attach the results of about:gpu on the affected machine to it? At this point I'm suspecting something configuration-specific. Thanks!
Done, and I think you're right that it may be a local issue. I did a browserstack test and there I had no issues. Issue created:

Comment 53 by, Jul 1 2016

It seems that Chrome is handling the backdrop-filter differently than other webkit based browsers. See attachments; Safari [9.1.1 (11601.6.17)] vs Chrome [52.0.2743.60 beta (64-bit)].

Chrome is applying the filter to any present box-shadows as well. I'd say: Apply the filter to inset box shadows, not to regular box shadows (treat as 'outside the bounding box').

Used filter:
  backdrop-filter: blur(10px);
  -webkit-backdrop-filter: blur(10px);

Box shadow:
  box-shadow: 0 1px 3px 0 rgba(0, 0, 0, 0.1);

(it doesn't matter what kind of box-sizing is applied)
157 KB View Download
125 KB View Download
I agree with @gabri, and have reported this earlier. It makes no sense that the shadow of the current element is blurred, the whole point of "backdrop" is to apply to the layer beneath.

Comment 55 by, Jul 1 2016

Blockedon: 618913
That bug has been reported as issue 618913. I'll set it as blocking this.
If it doesn’t go against the spec, I think that the filter should only apply to behind the area limited by `border-radius`.
Indeed an interesting feature - what's the status on the implementation of this? 

Comment 58 by, Sep 21 2016

Yeah, when is this coming out?
Hi there :) Any updates about this feature? We are really looking forward to use it in our products.
Working fine here if you enabled the new features, although it does NOT work with the -webkit prefix.  Also, it seems to only work on previous layer IMG tags, not on   images that are part of element's background ... ie works on elements, not element backgrounds.  I don't know if this is a bug or feature.

Comment 61 by, Sep 23 2016

The -webkit- prefixed property is not supposed to work, so this is by design.
I am not sure regarding the background-image. I expected it to be filtered as well.
But it is not.
I looking for this feature!!! 
Blockedon: 593307
Blockedon: 615722
Blockedon: 582219
Blockedon: 547937
Blockedon: 632979
Blockedon: 659501
jaydasika@, what is the current status of this work? Predictability program has set an OKR to gain traction on the top 50 starred bugs this quarter: either by closing them, stating what milestone the fix will ship, or setting a NextAction date so that we know when to check back.
NextAction: 2017-04-03
I am focusing this quarter completely on finishing up work on cc property trees and will not be able to do anything for this bug. So, setting the NextAction date to beginning of next quarter. 

Comment 74 Deleted

Thanks, jaydasika@. So, is this work planned for next quarter, or is that when you will assess if that is the case?
How does the work going? When can we expect to be able to use the feature? Thanks for informations and good luck !
Components: -Blink>CSS>Filters Blink>Compositing>Filters
NextAction: 2017-07-01
I don't expect much work to happen for this in Q2 as we decided not to have a OKR for this in Q2. Setting the NextAction date to beginning of next quarter. 
Blockedon: 626762
Owner: ----
Status: Available

Comment 81 by, May 13 2017

Hi. Does it mean it will be released in chrome on July 1st 2017? (version 62?)
I hope for it so much, this feature would be really game changing for web design, I can't wait for it !

Comment 83 by, May 13 2017

#81 - it only means the team will not get to it before July 1st. The team may get to it a lot later. No time frame at all.

Comment 84 by, May 13 2017

Oh ok. Thank you for the clarification. I was confused by this `Status:	Available`. Thanks!

Comment 85 by, May 13 2017

If the status is Fixed or Verified, it means that the feature is fully implemented (modulo bugs). The rest of them means it is not fully implemented yet.
Hallo! Just wanted to add (I am sure you already know this, but just incase) that when you set a border-radius, the filter does not abide by the rules. For instance, if you use the blur filter, you will still see a square blur, not a cornered blur.
I updated but I don't know how to re-open it. I think someone else needs to.

The border-radius bug is related to that one, because the basic problem is that the effect is not clipped to the edges of the background painting area.
The NextAction date has arrived: 2017-07-01

Comment 89 by, Jul 13 2017

I'd love to see this feature this year. It will change the look of the internet.

Comment 90 Deleted

I strongly endorse the Comment 89. Examples of real world use cases: blur filters in context menus, sidebars, toolbars, docks, are out there for a considerable amount of time now, firstly in macOS and iOS and more recently in Windows 10 with the Fluent Design System. It's more than time for the Web to evolve into a path that avoids us using hacks to solve trivial design problems. A terrible hack with duplicated background fixed images ( would be so easily solved with backdrop-filter (
@Eric: Backdrop blurs date as far back as Windows 7, aero theme. Not that it matters, just to agree it's about time we get this on the web. Gimmick or not, sometimes the web needs something exciting and beautiful. 

Would be great to get it working on chrome rather soon. I agree, I don't think it is only a gimmick, it adds value and new possibilities for the web.
I agree with everyone, Chrome really need this feature, It's anormal that Safari already have it for years instead of Chrome...
Do these comment have any effect? Does Google prioritize thing based on user feedback?

Comment 96 by, Jul 20 2017

#95 - they probably have a negative effect (waste the time of Chrome engineers).
Interested people should just star the issue instead of adding a me-too comment, unless it mentions a yet-unmentioned use case.
Concur with #93 - this is not some "nice to have" it really is a significant ability to filter the things below a div in a z-organized stack of elements. I will add that Android material design, ios/macos, and windows 10 fluent design all provide this kind of functionality.
Computationally blur is expensive. Hopefully Chromium developers are taking the time to carefully consider how to maintain good user experience (in terms of performance and battery life). 

Comment 99 by, Aug 14 2017

Hugely useful feature. Any chance of an update on general progress / prospects for general release?
yes, this would be awesome.

Comment 101 by, Aug 29 2017

my most expected feature of this year!
I would really like to see this feature land in Firefox (and all other browsers). It is such a simple and powerful way to achieve effects that make UIs easier on the eyes, more readable, etc. (Sharp text on top of blurred backgrounds is far easier to read and more 'natural' for our eyes to make sense of than the same text on top of a semi-opaque but still-crisp background.) 

The blur-behind paradigm has been crucial for Apple UIs for a very long time and it would be really great to have simple parity in this regard on the Web.

I know that a similar effect is possible by blurring everything except the foreground, but this is not a practical approach very often, and it breaks the principle that components/widgets/elements/etc should only care about their own concerns. With backdrop-filter, I can ship a modal dialog implementation with a backdrop that blurs whatever is behind it. I do not have to touch anything else in the document. Without backdrop-filter, I have no other choice but to go and blur everything else manually, which may not even be possible if the rest of the page is re-rendering itself and discarding my DOM manipulations.

Been using/testing this feature for the past few days. Yesterday after an update to Chrome the blur effect seems a lot more stable (it was a bit twitchy before, for lack of a better word)

Is this an indication that it will be ready soon? 

Blockedon: 767997
Is there any hint about a potential public release date yet?

From what I see in the with the flag enabled, the filter looks quite good actually.
The feature is on hold and no further development is happening. No timeline yet
on when it might be finished, sorry.
We can learn how to achieve this in vanilla WebGL faster than waiting for this to be released. xD

But seriously, this would be an awesome feature to have. Just imagine the beauty that UIs will have with this feature. It would be a huge benefit for the web if all browsers had this.
Other browsers: Edge, Windows 10 build 17063: CSS backdrop-filter is now enabled by default
Comment 106 from

For real? Is this a real statement about this highly requested and demanded feature? We users, we web designers and developers need this feature, is a all new way to build awesome UI's for our users! Please, don't let this feature to drop. 

By the way: Edge 17 support this feature by default in Windows 10 Insider Preview Build 17063. So we have to move to Edge?

 Issue 798267  has been merged into this issue.
It's been 2.5 years now of having a 80% implementation with no sign of getting to a full implementation. With Apple having this for years now, Edge having it soon and Firefox committed to it, this could be the year to bring this to the web across the board.

I really hope the priority gets bumped. It seems starring the issue is the go-to way for democratic voting, but the backlog seems full of issues with 10 times more stars for issues that are tiny, having little value to only a tiny user base. Whilst this is a design game changer across the board.

I respect that we don't fully control priority, but this one is so close and halting for so long, whilst being such a delightful feature. 

Sorry, I'm just passionate about this one. I can't help with coding but willing to help in testing.
All: please star this issue if you would like it implemented, rather than
commenting further. We use stars as one measure of whether to implement a 
Blockedon: 813796
I think chrome guys are that jealous of Apple, Since Apple products seems to use more blur filters including iOS. other than that no reason to implement this feature already in chrome.
#114 - Blur filters would be a very nice feature to have, both from the design aesthetics perspective, and also have more practical uses (eg focusing user attention on areas of the screen requiring their attention.)

Yes, Apple use it a lot, to good effect, so no harm in giving them credit for taking the lead. But we also see Edge supporting it, and Firefox committed to it too. So soon it will just be Chrome perceived as the one left behind, as the down-level browser with 'ugly' looking sites.

Jealous? Maybe, but more positively, excited with the anticipation of being able to use it once the bugs round the edges are ironed out. Either way, I'd encourage anyone who wants to see this to star it. Let's get it done!

Sign in to add a comment