1868737 - backdrop-filter css property is disabled in RDP session

Status: RESOLVED FIXED

(Core :: Graphics: WebRender, defect, P3)

Description

[Phoenix]

Attachment: Firefox1.PNG

When using Firefox in Microsoft RDP session, backdrop-filter css property is blocklisted by driver and causing menus with it applied to be transparent (see attached screenshot).
Setting layout.css.backdrop-filter.force-enabled fixing the issue, but it would be nice to have it working out of the box.
More details in this bug report initially filled for Jenkins: https://issues.jenkins.io/browse/JENKINS-72430

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:gw, could you have a look please?

For more information, please visit BugBot documentation.

Comment 2

[Glenn Watson [:gw]]

Would you be able to supply the output of your about:support when running RDP in this configuration?

Comment 3

[Phoenix]

Attachment: about:support from release/regular profile

Comment 4

[Phoenix]

Attachment: about:support from nightly/clean profile

Comment 5

[Phoenix]

Attached two reports from Firefox release and my regular profile, and current Nightly on clean profile, please check if they ok for you :)

Comment 6

[Glenn Watson [:gw]]

Looks like the relevant information is:

BACKDROP_FILTER:
default: available,
env: blocklisted, #BLOCKLIST_FEATURE_FAILURE_EMPTY_DRIVER_VERSION, Blocklisted; failure code FEATURE_FAILURE_EMPTY_DRIVER_VERSION

I'm not really sure why we block backdrop-filter in this case though, it's running on sw-wr so it should be fine to run it. Andrew, do you know much about the blocking here - should we ever block a feature for empty driver version if we're running sw-wr?

Comment 7

[Andrew Osmond [:aosmond] (he/him)]

We've been talking about what to do in these scenarios, and there are a set of features that should be allowed regardless.

Comment 8

[Andrew Osmond [:aosmond] (he/him)]

Attachment: Bug 1868737 - Allow minimal gfx features by default for uncertain configurations.

Some features such as the GPU process (except on Android), backdrop
filter (because it always works with Software WebRender), ANGLE (because
it is generally good) and out of process WebGL (we generally want to
remote WebGL for sandboxing purposes) are special, and should not be
disabled simply because we are uncertain about our configuration. In
these situations, disable most features, but keep these enabled by
default.

Comment 9

[Andrew Osmond [:aosmond] (he/him)]

Marking this was wontfix for 122 because I think this should ride the trains. If it causes minimal fuss, we can consider uplifting to ESR.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/03a4fbacc768
Allow minimal gfx features by default for uncertain configurations. r=jrmuizel

Comment 11

[Serban Stanca [:SerbanS]]

Backed out for causing talos performance tests related failures.

• Backout link
• Push with failures
• Failure Log
• Failure line: PROCESS-CRASH | MOZ_DIAGNOSTIC_ASSERT(eventWnd) (CreateWindowW for EventWindow failed twice) [@ nsAppShell::InitHiddenWindow::<lambda_11>::operator()] | tp5n

Comment 12

[Andrew Osmond [:aosmond] (he/him)]

It appears that we were failing to use the GPU process before because the vendor was 0x0, the GPU process crashes during initialization so we disable it, the test passes, but because it found minidumps, it fails and dumps them at the end, hence the diagnostic assert.

Comment 13

[Andrew Osmond [:aosmond] (he/him)]

I think the test is a bit tricky to solve because we actually want the behaviour the test is demonstrating in the real world. If we can't use the GPU process, fine, but we want to try first. We could flip a pref just for this test to force disable the GPU process.

Comment 14

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d6443c86506e
Allow minimal gfx features by default for uncertain configurations. r=jrmuizel,perftest-reviewers,kshampur

Comment 15

[Iulian Moraru]

https://hg.mozilla.org/mozilla-central/rev/d6443c86506e

Comment 17

[Ryan VanderMeulen [:RyanVM]]

Is this something we should backport to ESR? Would need a bit of rebasing if yes.

Comment 19

[Andrew Osmond [:aosmond] (he/him)]

I think we can be reasonably confident in an uplift yes. I will prep a patch.

Comment 20

[Andrew Osmond [:aosmond] (he/him)]

Actually if we uplift bug 1870159 as well it should merge cleanly, that is my recommendation.

Comment 21

[Andrew Osmond [:aosmond] (he/him)]

Comment on attachment 9370895 [details]
Bug 1868737 - Allow minimal gfx features by default for uncertain configurations.

ESR Uplift Approval Request

• If this is not a sec:{high,crit} bug, please state case for ESR consideration: Users with edge case configurations will be denied basic features like backdrop filters and the GPU process
• User impact if declined:
• Fix Landed on Version: 123
• Risk to taking this patch: Low
• Why is the change risky/not risky? (and alternatives if risky): We still deny most features, and the ones we will now keep are either guaranteed to work, or we can can recover gracefully. This patch requires bug 1870159 to be uplifted first.

Comment 22

[Ryan VanderMeulen [:RyanVM]]

Comment on attachment 9370895 [details]
Bug 1868737 - Allow minimal gfx features by default for uncertain configurations.

Approved for 115.8esr.

Comment 23

[Pulsebot]

https://hg.mozilla.org/releases/mozilla-esr115/rev/b72ded5fe488