Open Bug 1618013 Opened 1 year ago Updated 3 days ago

Enable backdrop-filter by default when WebRender is enabled

Categories

(Core :: Graphics: WebRender, task, P1)

task

Tracking

()

ASSIGNED

People

(Reporter: svoisen, Assigned: nordzilla)

References

(Blocks 1 open bug)

Details

(Whiteboard: [layout:backlog:78])

Attachments

(1 file, 1 obsolete file)

Whenever gfx.webrender.all is enabled, we should set layout.css.backdrop-filter.enabled to true. This will allow us to roll out backdrop-filter support to all systems that have WebRender turned on.

Blocks: 1578503
Priority: -- → P3
Whiteboard: [layout:backlog:2020q2]
Assignee: nobody → enordin
Status: NEW → ASSIGNED
Whiteboard: [layout:backlog:2020q2] → [layout:backlog:2020:76]
Whiteboard: [layout:backlog:2020:76] → [layout:backlog:77]
Depends on: 1633863
Whiteboard: [layout:backlog:77] → [layout:backlog:78]
  • Enable BackdropFilter pref by default
  • Add function IsBackdropFilterAavailable()
  • Use IsBackdropFilterAvailable for relevant WebIDL instead of pref
  • Add test for BackdropFilter availability
Attachment #9145934 - Attachment description: Bug 1618013 - Make BackdropFilter's Availability Depend on WebRender → Bug 1618013 - Make BackdropFilter's Availability Depend on WebRender r=emilio
Depends on: 1635584
Attachment #9145934 - Attachment is obsolete: true
Attachment #9145934 - Attachment is obsolete: false
Attachment #9145934 - Attachment is obsolete: true
Depends on: 1637437

Now that we triage by severity, setting priority to P1 to reflect backlog prioritization on this bug as either in-progress, or planned development in the near term. See https://wiki.mozilla.org/Platform/Layout#Backlog_Tracking_in_Bugzilla

Priority: P3 → P1

Resolution from intent-to-ship discussion is to release for early beta or earlier.

Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/7549c5a5df5a
Enable backdrop-filter for early beta r=emilio

This failed due to an unexpected pass on will-change-absbos-cb-003.html.

I had a prior patch which was intended to update all of the test expectations:
https://phabricator.services.mozilla.com/D74162

I apologize. I'm not sure how this one test slipped through the cracks.

I've updated the expectation for this test to only fail if not webrender.

Flags: needinfo?(enordin)
Pushed by cbrindusan@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cb9029d07271
Enable backdrop-filter for early beta r=emilio
See Also: → 1648323

NarcisB, sorry to cause you this trouble twice in a row.

I'm going to keep looking into this. Some of these WPTs seem like they may be inconsistent. I'm noticing some local failures on my macOS machine that are not showing up in your logs, and I also don't see what you reported in my pushes to try:

https://treeherder.mozilla.org/#/jobs?repo=try&revision=d9cb3cc5bd229212721a4888f9ea5264d6e565eb&selectedTaskRun=Ji655y0bSu-ntYb2Fd-GCw.0

Anyhow, given the recent bug that darkspirit reported, I'm going to hold off on trying to land this until I can investigate further. And I certainly don't want to land during code freeze.

Flags: needinfo?(enordin)

There's a r+ patch which didn't land and no activity in this bug for 2 weeks.
:nordzilla, could you have a look please?
For more information, please visit auto_nag documentation.

Flags: needinfo?(enordin)

This patch was backed out twice due to some failing WPTs and a newly reported bug. Thankfully, this patch itself is a one-line change to the default value of a preference and shouldn't be subject to bit rot. At the time, we were approaching code freeze, and I didn't feel comfortable landing with these issues popping up.

I still have to look into the cause of the WPT failures before I can consider flipping the preference again.

Flags: needinfo?(enordin)

Erik what is the status of this bug? This keeps getting brought up in various discussions on the web. WebRender seems to be more widely rolled out now.

Flags: needinfo?(enordin)

Hi Tom,

I was tasked with reworking our preferences so that backdrop-filter could be dependent on WebRender. That is, only available to be enabled if WebRender is enabled at the pref level.

This bug characterizes a small patch that would turn on backdrop-filter by default if WebRender is enabled.

Unfortunately, when I tried to land this patch, it was backed out due to some failing WPTs involving backdrop-filter itself.

So the current status is that we need to look into the tests that failed, and potentially tweak the backdrop-filter implementation to pass the tests.

I had a loose goal to try to look into this myself, but I never got around to it due to work on the new print UI. I don't have any experience with the actual backdrop-filter implementation itself: I only worked on the prefs, so this will require some amount of ramping up on this domain for me. I'm also open to someone else looking into the actual backdrop-filter implementation.

The pref work is all landed, just waiting on the switch to be flipped to on by default (which is what this patch does).

Is there a sense of priority for this feature now that WebRender is more established?

Flags: needinfo?(enordin) → needinfo?(evilpies)

I don't have any experience with the actual backdrop-filter implementation itself

Sounds like somebody from the graphics team should look into this.

Is there a sense of priority for this feature now that WebRender is more established?

Well I obviously can't speak for the WebRender people. My though was that now that we use WebRender a lot more enabling this is going to have a larger impact. It doesn't seem like this has a high priority though.

Flags: needinfo?(evilpies)
You need to log in before you can comment on or make changes to this bug.