Implement backdrop-filter from Filter Effects Module Level 2 (for the webrender graphics backend)
Categories
(Core :: Graphics, enhancement, P3)
Tracking
()
Tracking | Status | |
---|---|---|
firefox70 | --- | fixed |
People
(Reporter: jonnyscholes, Assigned: cbrewster)
References
(Blocks 2 open bugs, )
Details
(6 keywords, Whiteboard: [gfx-noted], [DevRel:P2] [layout:backlog:2019q3])
Attachments
(5 files)
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0 Build ID: 20150622004006 Steps to reproduce: Example URL: http://jsbin.com/fibokagifo/1/edit?html,css,output Steps to reproduce the problem: 1. Visit http://jsbin.com/fibokagifo/1/edit?html,css,output 2. The box's background should be a blurred version of its backdrop 3. Adjusting the sliders should change the effect Did this work before? No Does this work in other browsers? Nothing stable. It's slated for support in the Safari that drops in OSX 10.11 Corresponding Chromium issue: https://code.google.com/p/chromium/issues/detail?id=497522 Actual results: The backdrop-filter property isn't supported, so nothing. Expected results: The box has a background of a blurred version of its backdrop.
Updated•9 years ago
|
Updated•9 years ago
|
Updated•9 years ago
|
Comment 1•9 years ago
|
||
Backdrop filters are now supported in the latest webkit nightly https://www.webkit.org/blog/3632/introducing-backdrop-filters/
(In reply to Mahdi Dibaiee [:mahdi][:mdibaiee] from comment #1) > Backdrop filters are now supported in the latest webkit nightly > > https://www.webkit.org/blog/3632/introducing-backdrop-filters/ … prefixed with -webkit- Are we going to reintroduce the -moz- prefix here or stick with putting it behind a pref.
Comment 3•9 years ago
|
||
I'm not in a position to make a decision about this, maybe someone who is more relevant can answer.
Comment 4•9 years ago
|
||
Spec heroes & implementers: Would you mind reading over the spec and assessing if it is ready for implementation? If not, can you please provide input to the authors so this can move forward? I expect this to be the "next big thing" among Web Designers 'cause The Fruit is doin' it …
I'm neither a hero nor an implementer, but there doesn't seem to be much in the spec that could change.
I can't wait for this. This is one of the last things remaining (besides shader support (will that ever exist?)) to be able to make DOM-based apps that can compare with native. backdrop-filters coupled with 3D transforms will open many doors for creativity...
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment hidden (offtopic) |
Comment 14•9 years ago
|
||
Done: https://bugzilla.mozilla.org/show_bug.cgi?id=1232820
Comment 15•9 years ago
|
||
http://caniuse.com/#feat=css-backdrop-filter
Comment 16•8 years ago
|
||
backdrop-filter is more practical than filter.
Updated•8 years ago
|
Updated•8 years ago
|
Updated•8 years ago
|
My understanding is that this is the same feature that's been in SVG filters for ages, but that we've never implemented (bug 437554).
Comment 18•8 years ago
|
||
Except for https://github.com/w3c/fxtf-drafts/issues/53 .
Comment 19•7 years ago
|
||
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.
Comment 20•7 years ago
|
||
notechnicalvalue |
Why does it take browsers so long to implement great things? Mozilla, do you need more engineers? There seem to be plenty around here in the Bay Area...
Comment 21•7 years ago
|
||
Our pace implementing new CSS slowed over the last year because tremendous engineering effort was directed at making Firefox much faster. You can read all about it here: https://www.cnet.com/special-reports/mozilla-firefox-fights-back-against-google-chrome/ We are almost done with a great deal of that effort, and will soon be focusing people on implementing on new stuff rather than improving the old. Look for many more CSS properties shipping in 2018. And thanks for chiming in about what you want to see most. It does help in making sure important CSS properties are not overlooked.
Comment 22•7 years ago
|
||
That's really awesome, I'm looking forward to 57!
Comment 23•7 years ago
|
||
Not trying to appear to be rushing things, but I'd really like to see this in Firefox now that 57 is shipped to stable! Maybe Q1 2018 :)
Comment 24•7 years ago
|
||
If this helps, Edge implements and enables backdrop-filter in its latest Insider version: https://wpdev.uservoice.com/forums/257854-microsoft-edge-developer/suggestions/9160189-backdrop-filters Safari does it for long time and Chrome under a flag. Please, Firefox team, make it real.
Updated•7 years ago
|
Updated•7 years ago
|
Comment hidden (advocacy) |
Comment 26•6 years ago
|
||
https://caniuse.com/#feat=css-backdrop-filter Seems to be implemented in the next Edge, Chrome has it behind a flag and webkit has it behind a perfix. Other vendors are waiting for the real leader of the web to push this feature :-)
Comment 27•6 years ago
|
||
As this was turned into a meta-bug for Filter Effects Level 2, should we create a separate issue for 'backdrop-filter' blocking this one? Sebastian
Comment hidden (advocacy) |
Comment 29•6 years ago
|
||
(In reply to Sebastian Zartner [:sebo] from comment #27) > As this was turned into a meta-bug for Filter Effects Level 2, should we > create a separate issue for 'backdrop-filter' blocking this one? Thanks for the heads-up Sebastian. I have reverted the meta-morphosis (since this bug already has plenty of history for 'backdrop-filter' and am filing a new meta bug for Filter Effects Level 2. Stand by.
Updated•6 years ago
|
Updated•6 years ago
|
Comment 30•6 years ago
|
||
(In reply to Tantek Çelik from comment #29) > (In reply to Sebastian Zartner [:sebo] from comment #27) > > As this was turned into a meta-bug for Filter Effects Level 2, should we > > create a separate issue for `backdrop-filter` blocking this one? > > Thanks for the heads-up Sebastian. I have reverted the meta-morphosis (since > this bug already has plenty of history for `backdrop-filter` and am filing a > new meta bug for Filter Effects Level 2. Stand by. It’s also pointed to by the Firefox Platform Status website¹ as the bug for CSS `backdrop-filter`. Also, if we do implement this, then we should consider adding the `-webkit-backdrop-filter` prefix for webcompat since Safari currently implemets behind the `-webkit-` prefix², although Edge and Chrome aren’t currently implementing the `-webkit-` prefix, so I don’t really know if it’s really gonna be necessary. ¹ https://platform-status.mozilla.org/#css-backdrop-filter ² https://developer.mozilla.org/docs/Web/CSS/backdrop-filter#Browser_compatibility
Comment 31•6 years ago
|
||
(In reply to ExE Boss from comment #30) > > Also, if we do implement this, then we should consider adding the > `-webkit-backdrop-filter` prefix for webcompat since Safari currently > implemets behind the `-webkit-` prefix², although Edge and Chrome aren’t > currently implementing the `-webkit-` prefix, so I don’t really know if it’s > really gonna be necessary. By default we should avoid (rather than should consider) implementing any -webkit- prefix properties. Only when there is documented compat data that makes a case for it, should we bother with implementing. Mike, is -webkit-backdrop-filter anywhere on the compat radar?
Comment 32•6 years ago
|
||
From the graphics team side, there are two major blockers that are currently preventing this from being implemented in Firefox: - The graphics team is busy implementing WebRender and does not have the capacity to implement other graphics features at the moment. - The specification is imprecise in a crucial aspect and requires clarification. This is tracked in https://github.com/w3c/fxtf-drafts/issues/53 . Once the spec has been changed or clarified, we do not have objections to having this in Firefox.
Comment 33•6 years ago
|
||
I think this should be WONTFIX, since the backdrop-filter spec has been replaced by the `filter()` function: https://www.w3.org/TR/filter-effects/#FilterCSSImageValue
Comment 34•6 years ago
|
||
No it hasn't. The filter function has existed in a spec for longer than backdrop-filter, and it only filters the image you supply inside the background-image, whereas backdrop-filter filters "everything behind the element".
Comment 35•6 years ago
|
||
(In reply to Tantek Çelik from comment #31) > Only when there is documented compat data that makes a case for it, should > we bother with implementing. > > Mike, is -webkit-backdrop-filter anywhere on the compat radar? This hasn't come up for us yet, to my knowledge.
![]() |
||
Comment 36•6 years ago
|
||
Mass bug change to replace various 'parity' whiteboard flags with the new canonical keywords. (See bug 1443764 comment 13.)
Comment 37•6 years ago
|
||
This feature is getting hyped: https://css-tricks.com/the-backdrop-filter-css-property/
Comment 38•6 years ago
|
||
Polyfill ready: Demo: https://ahsane.github.io/backdrop-polyfill-chrome/index.html Source: https://github.com/AhsanE/backdrop-polyfill-chrome
Comment 39•6 years ago
|
||
(In reply to Tantek Çelik from comment #31) > (In reply to ExE Boss from comment #30) > > > > Also, if we do implement this, then we should consider adding the > > `-webkit-backdrop-filter` prefix for webcompat since Safari currently > > implemets behind the `-webkit-` prefix², although Edge and Chrome aren’t > > currently implementing the `-webkit-` prefix, so I don’t really know if it’s > > really gonna be necessary. > > By default we should avoid (rather than should consider) implementing any > -webkit- prefix properties. > > Only when there is documented compat data that makes a case for it, should > we bother with implementing. > > Mike, is -webkit-backdrop-filter anywhere on the compat radar? If I'm not mistaken, Edge currently requires the `-webkit` prefix on `backdrop-filter`, otherwise it doesn't render the blur. Not sure if/when they'll drop the prefix. Would love it if FF came in without the need for a prefix.
Comment 40•6 years ago
|
||
Why is the status of Safari "Developing" Safari release this years ago
Comment 41•6 years ago
|
||
(In reply to bh from comment #40) > Why is the status of Safari "Developing" Safari release this years ago Obviously, the page isn't up-to-date. You can provide a patch for it at https://github.com/mozilla/platform-status/. Sebastian
Comment hidden (advocacy) |
Comment 43•6 years ago
|
||
Will this https://www.bleepingcomputer.com/news/security/css-is-so-overpowered-it-can-deanonymize-facebook-users/ affect speed of implementation? Is there even a way to provide the filter without the security loophole?
Comment 44•6 years ago
|
||
(In reply to heyjoeday from comment #39) > If I'm not mistaken, Edge currently requires the `-webkit` prefix on > `backdrop-filter`, otherwise it doesn't render the blur. Not sure if/when > they'll drop the prefix. Would love it if FF came in without the need for a > prefix. I don't think a prefix is needed either. I'm pretty sure Edge will drop it in the future. Also, apple.com (the menu bar) uses both prefixed and unprefixed in their CSS code, suggesting this is how they intended it to be used.
Comment 45•6 years ago
|
||
Chrome is now working on that feature. https://bugs.chromium.org/p/chromium/issues/detail?id=497522#c134 Three months ago: > While we can't promise when the feature will be added, I wanted to let you know that we did hear your comments. We're going to try to make progress on this feature in the next few months. Three weeks ago: > We may restart work on this feature soon, please stay tuned. The next step is to fix an error in the specification. Today it was assigned to someone.
Comment 46•6 years ago
|
||
Safari and Edge both support this.
Updated•6 years ago
|
Comment hidden (me-too) |
Comment hidden (me-too) |
Comment hidden (advocacy) |
Comment 50•6 years ago
|
||
For all that are hoping that this feature gets implemented soon (like me), backdrop-filter
is listed in the priorities for 2019, see https://wiki.mozilla.org/CSS#Filter_Effects_Level_2.
Sebastian
Comment 51•6 years ago
|
||
Today's Blink intend to ship:
https://groups.google.com/a/chromium.org/forum/m/#!topic/blink-dev/GRl1_Qy97jM
Updated•5 years ago
|
Updated•5 years ago
|
Comment 52•5 years ago
|
||
Dear Sean Voisen,
Can you explain what means "Whiteboard: [gfx-noted], [DevRel:P2] → [gfx-noted], [DevRel:P2] [layout:backlog:2019q3]" ?
Thanks you.
Apparently the current spec draft is something that the WebKit folks consider to be unimplementable.
Comment 54•5 years ago
|
||
As of now, backdrop-filter is enabled by default without a flag in Chrome Canary: https://bugs.chromium.org/p/chromium/issues/detail?id=497522#c195.
Updated•5 years ago
|
Comment 55•5 years ago
|
||
(In reply to j.deboysere from comment #52)
Can you explain what means "Whiteboard: [gfx-noted], [DevRel:P2] → [gfx-noted], [DevRel:P2] [layout:backlog:2019q3]" ?
It's simply notes for our team (layout) that it is officially on our backlog of work for Q3 2019. Work on this will soon be underway.
Comment hidden (me-too) |
Assignee | ||
Comment 57•5 years ago
|
||
Assignee | ||
Comment 58•5 years ago
|
||
Depends on D39097
Assignee | ||
Comment 59•5 years ago
|
||
Depends on D39098
Updated•5 years ago
|
Updated•5 years ago
|
Comment hidden (me-too) |
Assignee | ||
Comment 61•5 years ago
|
||
Depends on D39099
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Comment 62•5 years ago
|
||
Fixes an issue when backdrop-filter is used many time on a page where we would
spend a large amount of time reevaluating render tasks when assigning task depths.
Depends on D40665
Updated•5 years ago
|
Updated•5 years ago
|
Updated•5 years ago
|
Assignee | ||
Updated•5 years ago
|
Triggered autoland.
Comment 64•5 years ago
|
||
Pushed by dholbert@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/b5d6ed62cda1 Part 1: Add backdrop-filter WebRender display items r=gw https://hg.mozilla.org/integration/autoland/rev/abdb4f5f3323 Part 2: Implement backdrop-filter in WebRender r=gw https://hg.mozilla.org/integration/autoland/rev/94f900c3b514 Part 3: Add backdrop-filter display items to Gecko r=mstange https://hg.mozilla.org/integration/autoland/rev/593868dee998 Part 4: Force a display list rebuild when backdrop-filter pref is toggled r=mstange https://hg.mozilla.org/integration/autoland/rev/0c820a515e16 Part 5: Add optimization to render task depth assignment r=gw,nical
Assignee | ||
Updated•5 years ago
|
![]() |
||
Comment 65•5 years ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/b5d6ed62cda1
https://hg.mozilla.org/mozilla-central/rev/abdb4f5f3323
https://hg.mozilla.org/mozilla-central/rev/94f900c3b514
https://hg.mozilla.org/mozilla-central/rev/593868dee998
https://hg.mozilla.org/mozilla-central/rev/0c820a515e16
Assignee | ||
Updated•5 years ago
|
Comment hidden (me-too) |
Updated•5 years ago
|
Comment 67•5 years ago
|
||
This says it's fixed in Firefox 70, it's not. I'm using Firefox 70, beta 3 on a site with backdrop-filter: blur(2px)
and it doesn't work. And when the developer tools are opened it says "invalid property name". Same for -webkit-backdrop-filter
and I even tried -moz-backdrop-filter
.
backdrop-filter
and -webkit-backdrop-filter
work in Edge, Chrome, and Safari.
Comment 68•5 years ago
|
||
(In reply to Wyatt from comment #67)
This says it's fixed in Firefox 70, it's not. I'm using Firefox 70, beta 3 on a site with
backdrop-filter: blur(2px)
and it doesn't work. And when the developer tools are opened it says "invalid property name". Same for-webkit-backdrop-filter
and I even tried-moz-backdrop-filter
.
backdrop-filter
and-webkit-backdrop-filter
work in Edge, Chrome, and Safari.
The fact that's implemented doesn't necessarily mean it's enabled. layout.css.backdrop-filter.enabled
is default-false.
Comment 69•5 years ago
|
||
(In reply to Emilio Cobos Álvarez (:emilio) from comment #68)
The fact that's implemented doesn't necessarily mean it's enabled.
layout.css.backdrop-filter.enabled
is default-false.
I have enabled layout.css.backdrop-filter.enabled
flag, but in testing on Nightly 71.0a1 (2019-09-03) (64-bit), it still isn't rendering.
The inspector doesn't say that backdrop-filter
is an invalid property name so it seems like it's trying, but not actually rendering. I tested both with and without vendor prefixes.
Comment 70•5 years ago
|
||
(In reply to Wyatt from comment #67)
This says it's fixed in Firefox 70, it's not. I'm using Firefox 70, beta 3 on a site with
backdrop-filter: blur(2px)
and it doesn't work. And when the developer tools are opened it says "invalid property name". Same for-webkit-backdrop-filter
and I even tried-moz-backdrop-filter
.
backdrop-filter
and-webkit-backdrop-filter
work in Edge, Chrome, and Safari.
This is correct, on Firefox Nightly 71.0a1 (2019-09-03), it also does not work with either backdrop-filter
or -webkit-backdrop-filter
(In reply to Emilio Cobos Álvarez (:emilio) from comment #68)
The fact that's implemented doesn't necessarily mean it's enabled.
layout.css.backdrop-filter.enabled
is default-false.
It does not work, even if layout.css.backdrop-filter.enabled
is set to true in about:config
Comment 71•5 years ago
|
||
It also won't work without WebRender enabled
Comment 72•5 years ago
|
||
(In reply to Daniel from comment #71)
It also won't work without WebRender enabled
Thanks, that did it. Working after enabling gfx.webrender.enabled
.
Comment 73•5 years ago
|
||
Turns out I'm wrong, enabling layout.css.backdrop-filter.enabled
as well as gfx.webrender.enabled
does work.
(In reply to Daniel from comment #71)
It also won't work without WebRender enabled
Thanks, Daniel. That helped.
For the record, I spun off bug 1578503 as the "main" bug for enabling backdrop-filter
support by default.
Comment 75•5 years ago
|
||
Playing with the JSBin example in comment #0, I noticed that backdrop-filter with a blur filter behaves oddly with text. Text behind an element with backdrop-filter: blur(3px)
looks as if it has a text shadow (sharp text on top of a blurry shadow) instead of just being blurred. In Chromium it looks as expected. https://jsbin.com/toyubawoka/edit?html,css,output demonstrates the issue.
Comment 76•5 years ago
|
||
I filed bug 1578703 for that.
Comment 77•5 years ago
|
||
This is already documented: https://developer.mozilla.org/en-US/docs/Web/CSS/backdrop-filter
And the compat-data already lists it as supported in Fx70 but behind a pref. I think we can call this one done in terms of docs.
Updated•5 years ago
|
Comment 78•5 years ago
|
||
Unfortunately in 71.0b1 it became bugged as:
"backdrop-filter: blur(10px)" blurs all text and some other HTMLElements in the whole document (<html>), not only the content below styled element.
In Firefox 70 this problem didn't exist.
Assignee | ||
Comment 79•5 years ago
|
||
Hi Bx, I can't seem to reproduce the issue, do you have a testcase I could look at?
Comment 80•5 years ago
|
||
(In reply to Connor Brewster [:cbrewster] from comment #79)
Hi Bx, I can't seem to reproduce the issue, do you have a testcase I could look at?
https://jsfiddle.net/ziom1/kjw2690e/
Changing "transform" or "opacity" property changes invalid blur -- so I have added buttons to check this. For example, changing default opacity (=1) to (0.999) resolves invalid appearance.
Furthermore, I detected that more elements with "backdrop-filter" cumulate the invalid effect.
Assignee | ||
Comment 81•5 years ago
|
||
(In reply to Bx from comment #80)
(In reply to Connor Brewster [:cbrewster] from comment #79)
Hi Bx, I can't seem to reproduce the issue, do you have a testcase I could look at?
https://jsfiddle.net/ziom1/kjw2690e/
Changing "transform" or "opacity" property changes invalid blur -- so I have added buttons to check this. For example, changing default opacity (=1) to (0.999) resolves invalid appearance.
Furthermore, I detected that more elements with "backdrop-filter" cumulate the invalid effect.
This is the expected behavior due to something called Backdrop Roots. You can read more about it in the spec: https://drafts.fxtf.org/filter-effects-2/#BackdropRoot
The backdrop root isolates how much content is included in the backdrop for processing the backdrop-filter effect. The primary motivation is to prevent significant performance degradation in the case of nested effects and to better specify what should happen when backdrop-filter is combined with opacity effects. You can read more about this in the link above.
Comment 82•5 years ago
|
||
(In reply to Connor Brewster [:cbrewster] from comment #81)
This is the expected behavior due to something called Backdrop Roots. You can read more about it in the spec: https://drafts.fxtf.org/filter-effects-2/#BackdropRoot
The backdrop root isolates how much content is included in the backdrop for processing the backdrop-filter effect. The primary motivation is to prevent significant performance degradation in the case of nested effects and to better specify what should happen when backdrop-filter is combined with opacity effects. You can read more about this in the link above.
Unfortunately, current "backdrop-filter" behavior is not as expected. You can see what it should be on Chrome, Safari and even Edge, where only the content below styled Element is affected (not all web page). None of the other browsers blurs buttons or text nodes in my example.
Currently backdrop-filter is inexpedient, changing parts where it shouldn't change (like in this JSFiddle: buttons and text nodes which are not even close to the backdrop-filter elements). Moreover, backdrop affects elements which are descendents of the "backdrop-filter" HTMLElement (elements over backdrop-filter are changed, which is ridiculous -- backdrop changes elements below and over HTMLElement? 😏).
Before 71.0 it was all good.
Comment 83•5 years ago
|
||
backdrop-filter
doesn't work at all for me on Firefox 70.0.1 despite layout.css.backdrop-filter.enabled
set to true
. See this simple example.
That likely means you don't have webrender enabled. (It's not enabled by default for everyone yet.) You can force it on by setting gfx.webrender.all
to true
and restarting Firefox. As noted in this bug's title, the implementation right now is only for the webrender backend (which is largely why we haven't enabled backdrop-filter by default yet).
(I tried your testcase on my machine with the webrender & backdrop-filter prefs turned on, and it works just fine - the corner of the blue square gets blurred.)
Comment 85•5 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #84)
That likely means you don't have webrender enabled. (It's not enabled by default for everyone yet.) You can force it on by setting
gfx.webrender.all
totrue
and restarting Firefox. As noted in this bug's title, the implementation right now is only for the webrender backend (which is largely why we haven't enabled backdrop-filter by default yet).(I tried your testcase on my machine with the webrender & backdrop-filter prefs turned on, and it works just fine - the corner of the blue square gets blurred.)
You're absolutely right! Works perfectly now, thank you :) Tried it on a much more complex and animated example as well and it's flawless so, congrats to all of you!
Any rough estimate on when both webrender and backdrop-filter will be enabled by default? :)
Comment 86•5 years ago
•
|
||
(In reply to Benjamin De Cock from comment #85)
Any rough estimate on when both webrender and backdrop-filter will be enabled by default? :)
webrender: already enabled by default for some fraction of our userbase (and I think (?) we're slowly ramping this up), though I believe there's some fraction that will never be able to have it on by default because of graphics hardware limitations.
backdrop-filter: not sure. it's complicated by the fact that it's only implemented for webrender right now, so we can't just turn on support for it in our css parser without "lying" on non-webrender configurations. (And there's a decent amount of work involved in implementing it on other backends; and on the other hand, we could theoretically just make the CSS parser only recognize backdrop-filter if webrender is enabled, but that's complicated too, because webrender can also get transparently turned off in the presence of some types of content, I think.) Anyway, that's tracked in bug 1578503, so you can follow along there.
Comment 87•5 years ago
|
||
(In reply to Daniel Holbert [:dholbert] from comment #86)
(In reply to Benjamin De Cock from comment #85)
Any rough estimate on when both webrender and backdrop-filter will be enabled by default? :)
webrender: already enabled by default for some fraction of our userbase (and I think (?) we're slowly ramping this up), though I believe there's some fraction that will never be able to have it on by default because of graphics hardware limitations.
backdrop-filter: not sure. it's complicated by the fact that it's only implemented for webrender right now, so we can't just turn on support for it in our css parser without "lying" on non-webrender configurations. (And there's a decent amount of work involved in implementing it on other backends; and on the other hand, we could theoretically just make the CSS parser only recognize backdrop-filter if webrender is enabled, but that's complicated too, because webrender can also get transparently turned off in the presence of some types of content, I think.) Anyway, that's tracked in bug 1578503, so you can follow along there.
Thank you!
Comment 88•5 years ago
|
||
I have now added a note at https://developer.mozilla.org/en-US/docs/Mozilla/Firefox/Experimental_features#backdrop-filter for this property.
Sebastian
Comment 89•4 years ago
|
||
I am just curious when this is slated to be enabled-by-default? It is not documented in the link mentioned above. Are there still failures with this feature I can track somewhere else?
That's tracked in bug 1578503; see in particular its dependency tree.
Description
•