Re: Intent to Implement: CSS backdrop-filter
On Thu, Jul 11, 2019 at 8:47 AM Jeff Muizelaar wrote: > I believe there's some precedent for this. I have a vague memory of a > browser which didn't have working 3d transforms if not run with a GPU. > Further, I'm not sure that having a broken backdrop filter is that > much worse an experience than the performance degradation that comes > from disabling GPU acceleration. That being said, I agree it's not an > ideal situation. > Sites may rely on the filter in ways that could affect legibility of content. For instance, text on top of content that has a background blur. Definitely not ideal. > I think we can probably postpone making a decision about this until we > have a working implementation on top of WebRender. We'll then be in a > better spot to evaluate the work needed to make this work with > non-WebRender vs waiting for WebRender everywhere vs the weirdness of > partially shipping it as proposed here. > I agree with this plan of attack. The WR implementation can help us assess the level-of-work and timing for the non-WR implementation (vs waiting for WR to ship everywhere). Which was essentially the plan all along anyway :) That said, I think the last option (partial shipping) is not really an option at all. Sean ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
On Thu, Jul 11, 2019 at 11:28 AM L. David Baron wrote: > I don't think having a CSS feature that stops working if the GPU > process crashes is acceptable. It's not a coherent story to web > developers, and it means that once sites start relying on the > feature (which they'll think they can do because it looks like it > works), pages will be broken for some portion of our users. I believe there's some precedent for this. I have a vague memory of a browser which didn't have working 3d transforms if not run with a GPU. Further, I'm not sure that having a broken backdrop filter is that much worse an experience than the performance degradation that comes from disabling GPU acceleration. That being said, I agree it's not an ideal situation. I think we can probably postpone making a decision about this until we have a working implementation on top of WebRender. We'll then be in a better spot to evaluate the work needed to make this work with non-WebRender vs waiting for WebRender everywhere vs the weirdness of partially shipping it as proposed here. -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
On Thursday 2019-07-11 10:59 -0400, Jeff Muizelaar wrote: > On Thu, Jul 11, 2019 at 10:46 AM Emilio Cobos Álvarez > wrote: > > On 7/10/19 11:01 PM, Connor Brewster wrote: > > > Hi David, > > > > > >> It's not clear to me what this option means in terms of what you're > > >> proposing to implement and ship. @supports is a feature that web > > >> developers can use -- and it should clearly match whether the > > >> feature is supported. However, I think what you're suggesting here > > >> is that you might ship the feature only when WebRender is enabled -- > > >> I think that's something that requires further discussion, given the > > >> confusion it would cause in the web development world. It also > > >> seems (?) like you're suggesting something else about limiting which > > >> filters are usable to only those that have a GPU implementation in > > >> WebRender -- but it's not clear to me if that's for backdrop-filter > > >> only, or also for the filter property -- when WebRender is enabled. > > > > > > The idea here is that @supports would reflect whether or not > > > backdrop-filter and WebRender are enabled. This would allow web > > > authors to add a fallback style if needed. I do agree that this would > > > cause some confusion and needs more discussion. > > > > This seems pretty hard to do right / pretty awkward. @supports must > > reflect whether the property parses. Not enabling the property if > > webrender is not enabled seems hacky, but doable. > > > > But if you have WebRender enabled and your GPU process crashes, going > > all the way back to the style system to invalidate everything doesn't > > seem trivial / worth the effort. It seems pretty hard actually. > > I feel like having the wrong results from @supports in this case is > probably acceptable. > I suspect background-filter is rarely used in ways that lying in > @supports causes a website to become unusable. > > I see disabling it in @supports as sort a best effort kind of thing as > opposed to needing to be perfect. I don't think having a CSS feature that stops working if the GPU process crashes is acceptable. It's not a coherent story to web developers, and it means that once sites start relying on the feature (which they'll think they can do because it looks like it works), pages will be broken for some portion of our users. -David -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
On Thu, Jul 11, 2019 at 10:46 AM Emilio Cobos Álvarez wrote: > On 7/10/19 11:01 PM, Connor Brewster wrote: > > Hi David, > > > >> It's not clear to me what this option means in terms of what you're > >> proposing to implement and ship. @supports is a feature that web > >> developers can use -- and it should clearly match whether the > >> feature is supported. However, I think what you're suggesting here > >> is that you might ship the feature only when WebRender is enabled -- > >> I think that's something that requires further discussion, given the > >> confusion it would cause in the web development world. It also > >> seems (?) like you're suggesting something else about limiting which > >> filters are usable to only those that have a GPU implementation in > >> WebRender -- but it's not clear to me if that's for backdrop-filter > >> only, or also for the filter property -- when WebRender is enabled. > > > > The idea here is that @supports would reflect whether or not > > backdrop-filter and WebRender are enabled. This would allow web > > authors to add a fallback style if needed. I do agree that this would > > cause some confusion and needs more discussion. > > This seems pretty hard to do right / pretty awkward. @supports must > reflect whether the property parses. Not enabling the property if > webrender is not enabled seems hacky, but doable. > > But if you have WebRender enabled and your GPU process crashes, going > all the way back to the style system to invalidate everything doesn't > seem trivial / worth the effort. It seems pretty hard actually. I feel like having the wrong results from @supports in this case is probably acceptable. I suspect background-filter is rarely used in ways that lying in @supports causes a website to become unusable. I see disabling it in @supports as sort a best effort kind of thing as opposed to needing to be perfect. -Jeff ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
On 7/10/19 11:01 PM, Connor Brewster wrote: Hi David, It's not clear to me what this option means in terms of what you're proposing to implement and ship. @supports is a feature that web developers can use -- and it should clearly match whether the feature is supported. However, I think what you're suggesting here is that you might ship the feature only when WebRender is enabled -- I think that's something that requires further discussion, given the confusion it would cause in the web development world. It also seems (?) like you're suggesting something else about limiting which filters are usable to only those that have a GPU implementation in WebRender -- but it's not clear to me if that's for backdrop-filter only, or also for the filter property -- when WebRender is enabled. The idea here is that @supports would reflect whether or not backdrop-filter and WebRender are enabled. This would allow web authors to add a fallback style if needed. I do agree that this would cause some confusion and needs more discussion. This seems pretty hard to do right / pretty awkward. @supports must reflect whether the property parses. Not enabling the property if webrender is not enabled seems hacky, but doable. But if you have WebRender enabled and your GPU process crashes, going all the way back to the style system to invalidate everything doesn't seem trivial / worth the effort. It seems pretty hard actually. In particular, right now we don't re-parse stylesheets when you toggle prefs for example (you need to reload or such). But the properties keep working. In this case the feature would stop working completely, while you have declarations on the page that set it and can read it via `cssText` (not via CSSOM anymore though, presumably), and existing @supports rules would keep matching true. -- Emilio With regard to limiting the filters available for backdrop-filter, I was trying to say that we would need to make sure that support is added to WebRender for all currently unsupported filters. I do not think it would be a good idea to ship backdrop-filter with only a subset of filters working. Currently, the filter property will fallback to the software renderer if an unsupported filter is encountered, this isn't an option for backdrop-filter if it is not implemented in the other backends. -Connor ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
Hi David, > It's not clear to me what this option means in terms of what you're > proposing to implement and ship. @supports is a feature that web > developers can use -- and it should clearly match whether the > feature is supported. However, I think what you're suggesting here > is that you might ship the feature only when WebRender is enabled -- > I think that's something that requires further discussion, given the > confusion it would cause in the web development world. It also > seems (?) like you're suggesting something else about limiting which > filters are usable to only those that have a GPU implementation in > WebRender -- but it's not clear to me if that's for backdrop-filter > only, or also for the filter property -- when WebRender is enabled. The idea here is that @supports would reflect whether or not backdrop-filter and WebRender are enabled. This would allow web authors to add a fallback style if needed. I do agree that this would cause some confusion and needs more discussion. With regard to limiting the filters available for backdrop-filter, I was trying to say that we would need to make sure that support is added to WebRender for all currently unsupported filters. I do not think it would be a good idea to ship backdrop-filter with only a subset of filters working. Currently, the filter property will fallback to the software renderer if an unsupported filter is encountered, this isn't an option for backdrop-filter if it is not implemented in the other backends. -Connor ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
On Monday 2019-07-08 15:21 -0700, Connor Brewster wrote: > Hi Ehsan, > > Currently, the plan is to develop this feature behind a pref flag that will > be off by default. We haven't decided the best way forward for enabling > this feature by default yet. We have two possible options: > 1. Add backdrop filter support to the other render backends. This seems like a reasonable option. > 2. Rely on an @supports media query to determine if backdrop-filter is > supported (this would check for the backdrop-filter pref flag and check if > WebRender is enabled). If we choose this route, we need to remove any > dynamic fallbacks to the software renderer that may occur when using > backdrop-filter. Currently WebRender does not support all SVG filters, so > these would need to be fully implemented for this approach to work. It's not clear to me what this option means in terms of what you're proposing to implement and ship. @supports is a feature that web developers can use -- and it should clearly match whether the feature is supported. However, I think what you're suggesting here is that you might ship the feature only when WebRender is enabled -- I think that's something that requires further discussion, given the confusion it would cause in the web development world. It also seems (?) like you're suggesting something else about limiting which filters are usable to only those that have a GPU implementation in WebRender -- but it's not clear to me if that's for backdrop-filter only, or also for the filter property -- when WebRender is enabled. -David > > > * Do we have other web-exposed features that are only supported when > WebRender is enabled? > > I don't believe we have any other web-exposed features only supported by > WebRender at the moment. > > > * How do we plan to communicate to web developers (who may not > necessarily know/care what WebRender is) where this feature is usable? > > This is a good thing to keep in mind when determining the right approach. > If we decide to implement backdrop-filter on all backends, this won't be an > issue; otherwise, if we go with approach 2, we would need to tell web > developers to rely on the @supports media query. > > > * What happens to the DevTools integration a) when WebRender is disabled > on the target Firefox instance, and b) when WebRender is disabled on the > target Firefox instance but enabled on the host instance (e.g. when > debugging Fennec on Windows with the right NVIDIA GPU driver). > > Currently, DevTools only checks if the backdrop-filter pref is enabled and > doesn't check if WebRender is enabled. If we decide on approach 2, we would > need to check for the cases that you mentioned. > > Thanks, > Connor > > > On Fri, Jul 5, 2019 at 7:23 AM Ehsan Akhgari > wrote: > > > On Mon, Jul 1, 2019 at 8:54 PM Connor Brewster > > wrote: > > > >> Platform coverage: All platforms using the Gecko rendering engine > >> (WebRender enabled only) > >> > >> Target release: Firefox 71 (WebRender enabled only) > >> > >> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060 > >> > > > > Hi Connor, > > > > Since this feature is only enabled based on WebRender being enabled, I > > have a few questions for you: > > > > * Do we have other web-exposed features that are only supported when > > WebRender is enabled? > > > > * How do we plan to communicate to web developers (who may not necessarily > > know/care what WebRender is) where this feature is usable? > > > > * What happens to the DevTools integration a) when WebRender is disabled > > on the target Firefox instance, and b) when WebRender is disabled on the > > target Firefox instance but enabled on the host instance (e.g. when > > debugging Fennec on Windows with the right NVIDIA GPU driver). > > > > Thanks, > > -- > > Ehsan > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform -- 턞 L. David Baron http://dbaron.org/ 턂 턢 Mozilla https://www.mozilla.org/ 턂 Before I built a wall I'd ask to know What I was walling in or walling out, And to whom I was like to give offense. - Robert Frost, Mending Wall (1914) ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
Hi Tom, > In particular, this one looks like it has all the same > concerns/problems with filters being applied to sensitive third party > content, and attacks that use timing to read that content. Are these > going to be tested for/addressed during implementation? We are not aware of any new attacks that will be introduced by backdrop-filter that are not already possible via the filter property as both properties will share the same filtering implementation. This feature will be preferenced off by default and we will have some time to experiment and check for these kinds of attacks before enabling the feature by default. -Connor On Fri, Jul 5, 2019 at 7:11 AM Tom Ritter wrote: > Just a note: we have a new template for Intent to X here: > https://wiki.mozilla.org/ExposureGuidelines > > In particular, this one looks like it has all the same > concerns/problems with filters being applied to sensitive third party > content, and attacks that use timing to read that content. Are these > going to be tested for/addressed during implementation? > > -tom > > On Thu, Jul 4, 2019 at 7:09 PM Connor Brewster > wrote: > > > > Clarification: backfrop-filter will *not* be restricted to secure > contexts. > > > > On Tue, Jun 25, 2019 at 4:30 PM Connor Brewster > > wrote: > > > > > Summary: The CSS backdrop-filter property allows web authors to > specify a > > > filter to be applied to an element's backdrop. It can be used to create > > > interesting visual effects that are commonly used in UI design. > > > > > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1178765 > > > > > > Standard: > https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty > > > > > > Platform coverage: All platforms using the Gecko rendering engine > > > (WebRender enabled only) > > > > > > Target release: Firefox 71 (WebRender enabled only) > > > > > > Preference behind which this will be implemented: > > > layout.css.backdrop-filter.enabled > > > > > > Is this feature enabled by default in sandboxed iframes? Yes > > > > > > DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060 > > > > > > Do other browser engines implement this? WebKit (since version 9, > behind > > > -webkit- prefix), Blink (since version 47, Behind "Enable Experimental > Web > > > Platform Features" preference) > > > > > > web-platform tests: > > > > https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/filter-effects > > > > > > Is this feature restricted to secure contexts? Yes > > > > > > Connor Brewster > > > > > ___ > > dev-platform mailing list > > dev-platform@lists.mozilla.org > > https://lists.mozilla.org/listinfo/dev-platform > ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
On Mon, Jul 8, 2019 at 6:22 PM Connor Brewster wrote: > Hi Ehsan, > > Currently, the plan is to develop this feature behind a pref flag that > will be off by default. We haven't decided the best way forward for > enabling this feature by default yet. We have two possible options: > 1. Add backdrop filter support to the other render backends. > 2. Rely on an @supports media query to determine if backdrop-filter is > supported (this would check for the backdrop-filter pref flag and check if > WebRender is enabled). If we choose this route, we need to remove any > dynamic fallbacks to the software renderer that may occur when using > backdrop-filter. Currently WebRender does not support all SVG filters, so > these would need to be fully implemented for this approach to work. > Thanks, this all sounds good! > > * Do we have other web-exposed features that are only supported when > WebRender is enabled? > > I don't believe we have any other web-exposed features only supported by > WebRender at the moment. > > > * How do we plan to communicate to web developers (who may not > necessarily know/care what WebRender is) where this feature is usable? > > This is a good thing to keep in mind when determining the right approach. > If we decide to implement backdrop-filter on all backends, this won't be an > issue; otherwise, if we go with approach 2, we would need to tell web > developers to rely on the @supports media query. > > > * What happens to the DevTools integration a) when WebRender is disabled > on the target Firefox instance, and b) when WebRender is disabled on the > target Firefox instance but enabled on the host instance (e.g. when > debugging Fennec on Windows with the right NVIDIA GPU driver). > > Currently, DevTools only checks if the backdrop-filter pref is enabled and > doesn't check if WebRender is enabled. If we decide on approach 2, we would > need to check for the cases that you mentioned. > > Thanks, > Connor > > > On Fri, Jul 5, 2019 at 7:23 AM Ehsan Akhgari > wrote: > >> On Mon, Jul 1, 2019 at 8:54 PM Connor Brewster >> wrote: >> >>> Platform coverage: All platforms using the Gecko rendering engine >>> (WebRender enabled only) >>> >>> Target release: Firefox 71 (WebRender enabled only) >>> >>> DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060 >>> >> >> Hi Connor, >> >> Since this feature is only enabled based on WebRender being enabled, I >> have a few questions for you: >> >> * Do we have other web-exposed features that are only supported when >> WebRender is enabled? >> >> * How do we plan to communicate to web developers (who may not >> necessarily know/care what WebRender is) where this feature is usable? >> >> * What happens to the DevTools integration a) when WebRender is disabled >> on the target Firefox instance, and b) when WebRender is disabled on the >> target Firefox instance but enabled on the host instance (e.g. when >> debugging Fennec on Windows with the right NVIDIA GPU driver). >> >> Thanks, >> -- >> Ehsan >> > -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
On Mon, Jul 1, 2019 at 8:54 PM Connor Brewster wrote: > Platform coverage: All platforms using the Gecko rendering engine > (WebRender enabled only) > > Target release: Firefox 71 (WebRender enabled only) > > DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060 > Hi Connor, Since this feature is only enabled based on WebRender being enabled, I have a few questions for you: * Do we have other web-exposed features that are only supported when WebRender is enabled? * How do we plan to communicate to web developers (who may not necessarily know/care what WebRender is) where this feature is usable? * What happens to the DevTools integration a) when WebRender is disabled on the target Firefox instance, and b) when WebRender is disabled on the target Firefox instance but enabled on the host instance (e.g. when debugging Fennec on Windows with the right NVIDIA GPU driver). Thanks, -- Ehsan ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Re: Intent to Implement: CSS backdrop-filter
Just a note: we have a new template for Intent to X here: https://wiki.mozilla.org/ExposureGuidelines In particular, this one looks like it has all the same concerns/problems with filters being applied to sensitive third party content, and attacks that use timing to read that content. Are these going to be tested for/addressed during implementation? -tom On Thu, Jul 4, 2019 at 7:09 PM Connor Brewster wrote: > > Clarification: backfrop-filter will *not* be restricted to secure contexts. > > On Tue, Jun 25, 2019 at 4:30 PM Connor Brewster > wrote: > > > Summary: The CSS backdrop-filter property allows web authors to specify a > > filter to be applied to an element's backdrop. It can be used to create > > interesting visual effects that are commonly used in UI design. > > > > Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1178765 > > > > Standard: https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty > > > > Platform coverage: All platforms using the Gecko rendering engine > > (WebRender enabled only) > > > > Target release: Firefox 71 (WebRender enabled only) > > > > Preference behind which this will be implemented: > > layout.css.backdrop-filter.enabled > > > > Is this feature enabled by default in sandboxed iframes? Yes > > > > DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060 > > > > Do other browser engines implement this? WebKit (since version 9, behind > > -webkit- prefix), Blink (since version 47, Behind "Enable Experimental Web > > Platform Features" preference) > > > > web-platform tests: > > https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/filter-effects > > > > Is this feature restricted to secure contexts? Yes > > > > Connor Brewster > > > ___ > dev-platform mailing list > dev-platform@lists.mozilla.org > https://lists.mozilla.org/listinfo/dev-platform ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
Intent to Implement: CSS backdrop-filter
Summary: The CSS backdrop-filter property allows web authors to specify a filter to be applied to an element's backdrop. It can be used to create interesting visual effects that are commonly used in UI design. Bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1178765 Standard: https://drafts.fxtf.org/filter-effects-2/#BackdropFilterProperty Platform coverage: All platforms using the Gecko rendering engine (WebRender enabled only) Target release: Firefox 71 (WebRender enabled only) Preference behind which this will be implemented: layout.css.backdrop-filter.enabled Is this feature enabled by default in sandboxed iframes? Yes DevTools bug: https://bugzilla.mozilla.org/show_bug.cgi?id=1561060 Do other browser engines implement this? WebKit (since version 9, behind -webkit- prefix), Blink (since version 47, Behind "Enable Experimental Web Platform Features" preference) web-platform tests: https://searchfox.org/mozilla-central/source/testing/web-platform/tests/css/filter-effects Is this feature restricted to secure contexts? Yes Connor Brewster ___ dev-platform mailing list dev-platform@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-platform
