(In reply to Gregory Pappas from comment #2) > With WebRender and backdrop-filter force-enabled, I got [this range](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d09edbe2abfec5298b39ab5b30d45bf20b8bbe33&tochange=9596d7f4a7457bccc78cadf9c39bcc9c4b5b97f8) with mozregression. Suspects include bug 1578777, bug 1581307. Botond, Sotaro, what do you think? This does seem to be a regression from bug 1578777. The culprit appears to be https://phabricator.services.mozilla.com/D46060, which was intended to be just a refactoring, but accidentally introduced a functional change: it factored out a helper function to be shared by `nsDisplayFilters::CanCreateWebRenderCommands` and `nsDisplayBackdropFilters::CanCreateWebRenderCommands`, without realizing that the first was looking at `StyleEffects()->mFilters` and the second was looking at `StyleEffects()->mBackdropFilters`. The helper function looked at `StyleEffects()->mFilters`, thereby giving an incorrect answer when called from `nsDisplayBackdropFilters::CanCreateWebRenderCommands`. The effect of this function was to [gate](https://searchfox.org/mozilla-central/rev/4375178c34ccbcedffb97b1e44f1f8c8d55eee39/layout/generic/nsFrame.cpp#3083) the creation of an `nsDisplayBackdropFilters` display item. That condition was removed in bug 1423746, whose commit message includes: ``` Remove the BackdropFilters::CanCreateWebrenderCommands call because it was testing for StyleSVGEffects::mFilters rather than mBackdropFilters, so it was doing nothing. ``` I suspect that the correct implementation returned false at the time, thereby inhibiting the creation of an `nsDisplayBackdropFilters` display item, and resulting in rendering the element without the backdrop filter.
Bug 1787623 Comment 7 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Gregory Pappas from comment #2) > With WebRender and backdrop-filter force-enabled, I got [this range](https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=d09edbe2abfec5298b39ab5b30d45bf20b8bbe33&tochange=9596d7f4a7457bccc78cadf9c39bcc9c4b5b97f8) with mozregression. Suspects include bug 1578777, bug 1581307. Botond, Sotaro, what do you think? This does seem to be a regression from bug 1578777. The culprit appears to be https://phabricator.services.mozilla.com/D46060, which was intended to be just a refactoring, but accidentally introduced a functional change: it factored out a helper function to be shared by `nsDisplayFilters::CanCreateWebRenderCommands` and `nsDisplayBackdropFilters::CanCreateWebRenderCommands`, without realizing that the first was looking at `StyleEffects()->mFilters` and the second was looking at `StyleEffects()->mBackdropFilters`. The helper function looked at `StyleEffects()->mFilters`, thereby giving an incorrect answer when called from `nsDisplayBackdropFilters::CanCreateWebRenderCommands`. The effect of this function was to [gate](https://searchfox.org/mozilla-central/rev/4375178c34ccbcedffb97b1e44f1f8c8d55eee39/layout/generic/nsFrame.cpp#3083) the creation of an `nsDisplayBackdropFilters` display item. That condition was removed in bug 1423746, whose commit message includes: > Remove the BackdropFilters::CanCreateWebrenderCommands call because it > was testing for StyleSVGEffects::mFilters rather than mBackdropFilters, > so it was doing nothing. I suspect that the correct implementation returned false at the time, thereby inhibiting the creation of an `nsDisplayBackdropFilters` display item, and resulting in rendering the element without the backdrop filter.