1678652 - failIfMajorPerformanceCaveat causes website breakage since 83

Status: VERIFIED FIXED

(Core :: Graphics: CanvasWebGL, defect, P1)

Description

[Pat Suwalski]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:83.0) Gecko/20100101 Firefox/83.0

Steps to reproduce:

Upgraded to Firefox 83 on Ubuntu 20.10 on Wayland.

Actual results:

When I try to launch a webGL game:
Failed to create WebGL context: failIfMajorPerformanceCaveat: Compositor is not hardware-accelerated.

Specifically Pixi says:
Error: WebGL unsupported in this browser, use "pixi.js-legacy" for fallback canvas2d support.

Expected results:

The game should have launched. There is no reason WebGL should fail.

Comment 1

[Pat Suwalski]

Downgrading to FIrefox 82 works, but is not workable. It forces me to create a new profile, so I lose everything I've built up over the last 18 years.

Comment 2

[Pat Suwalski]

Managed to restore functionality with --allow-downgrade. But this is obviously not a long-term solution.

Comment 3

[Pat Suwalski]

Per Ubuntu developers' suggestion, I tried the upstream build of Firefox (83.0.2), and it behaves the same way. That suggests this is an issue in Firefox and not Ubuntu's build and packaging.

Comment 4

[michaelspohn]

Same problem happens under Windows 10 (1909) with an AMD Radeon HD 6450 graphics card.

Comment 5

[Mathias Panzenböck]

Same problem for me with Firefox 83.0 (64bit) under Fedora Linux, using the official Firefox from the Mozilla website, when trying to load the 3D view of Google Maps. Have to use Google Chrome for that now. :(
Graphics Card: GeForce GTX 760
NVIDIA Driver Version: 455.38

Comment 6

[Pat Suwalski]

Can you guys try the Firefox 84b2 build? I tried it from the tarball and it worked perfectly.

Comment 7

[michaelspohn]

(In reply to Pat Suwalski from comment #6)

Can you guys try the Firefox 84b2 build? I tried it from the tarball and it worked perfectly.

No change, still broken on Windows 10...

Comment 8

[michaelspohn]

(In reply to michaelspohn from comment #7)

(In reply to Pat Suwalski from comment #6)

Can you guys try the Firefox 84b2 build? I tried it from the tarball and it worked perfectly.

No change, still broken on Windows 10...

Fun fact: Chrome 87.0.4280.66 and Edge 87.0.664.47 also do not support WebGL on Google Maps anymore No 3D-View available.
The "good old" Internet Explorer 11.1198.18362.0 is the only browser that still works just fine.
But hey, it's 2020! What do you expect? 🤣

Comment 9

[Tom S. (please needinfo tschuster)]

Could you open about:support, click the "Copy text to clipboard" button, come back to this bug, click the "Attach New File" button above, and paste into the "File:" box and submit that troubleshooting information, please.

Comment 10

[Dan Dascalescu]

Attachment: Attached about:config per instructions

Comment 11

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

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

For more information, please visit auto_nag documentation.

Comment 12

[Kelsey Gilbert [:jgilbert]]

(In reply to michaelspohn from comment #8)

(In reply to michaelspohn from comment #7)

(In reply to Pat Suwalski from comment #6)

Can you guys try the Firefox 84b2 build? I tried it from the tarball and it worked perfectly.

No change, still broken on Windows 10...

Fun fact: Chrome 87.0.4280.66 and Edge 87.0.664.47 also do not support WebGL on Google Maps anymore No 3D-View available.
The "good old" Internet Explorer 11.1198.18362.0 is the only browser that still works just fine.
But hey, it's 2020! What do you expect? 🤣

It sounds like the Google Maps team started using failIfMajorPerformanceCaveat, but might be going about it in a user-hostile way!
For Firefox, if you check in the Web Console for that page, if you get a message that mentions failIfMajorPerformanceCaveat, then you can bypass this to restore webgl creation via about:config, by setting "webgl.disable-fail-if-major-performance-caveat" to "true"!
Does that help for you?

Comment 13

[michaelspohn]

(In reply to Jeff Gilbert [:jgilbert] from comment #12)

(In reply to michaelspohn from comment #8)

(In reply to michaelspohn from comment #7)

(In reply to Pat Suwalski from comment #6)

Can you guys try the Firefox 84b2 build? I tried it from the tarball and it worked perfectly.

No change, still broken on Windows 10...

Fun fact: Chrome 87.0.4280.66 and Edge 87.0.664.47 also do not support WebGL on Google Maps anymore No 3D-View available.
The "good old" Internet Explorer 11.1198.18362.0 is the only browser that still works just fine.
But hey, it's 2020! What do you expect? 🤣

It sounds like the Google Maps team started using failIfMajorPerformanceCaveat, but might be going about it in a user-hostile way!
For Firefox, if you check in the Web Console for that page, if you get a message that mentions failIfMajorPerformanceCaveat, then you can bypass this to restore webgl creation via about:config, by setting "webgl.disable-fail-if-major-performance-caveat" to "true"!
Does that help for you?

I installed a more recent driver for my graphics card, now the bug is fixed for me. It seems like Mozilla blocked the old driver because of crashes. See also https://bugzilla.mozilla.org/show_bug.cgi?id=1679610

Comment 15

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

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

For more information, please visit auto_nag documentation.

Comment 16

[Dan Dascalescu]

I don't know if Google Maps changed something, but after setting gfx.webrender.all to true and restarting Firefox 83, I do get 3D satellite maps.

Comment 17

[Pat Suwalski]

Although Firefox 84b2 from official binaries worked fine, Firefox 84.0 from official binaries (firefox-84.0.tar.bz2) does not.

Setting gfx.webrender.all as suggested above does work.

This appears to be a capability detection issue.

Comment 18

[Kelsey Gilbert [:jgilbert]]

After bug 1680595, it should be more clear to (power) users what they can do to mitigate this.

Functionality here is, I think, working as intended now. Unfortunately the specified behavior causes certain websites (which arguably may have made poor choices) work worse for our users, whereas before things were maybe slower than they could have been, but otherwise functional.

With that in mind, since we're now following failIfMajorPerformanceCaveat spec properly, it's causing breakage. This bug is tracking the user pain-point. In order to solve the user pain-point, we might ditch failIfMajorPerformanceCaveat as accidentally-user-hostile for the time being.

Two choices:

1. Call out these bad websites, and try outreach/education
2. Re-evaluate the failIfMajorPerformanceCaveat mechanism entirely

Comment 19

[Kelsey Gilbert [:jgilbert]]

Honestly at this point I'm tending towards #2.
Websites had the chance to handle this well and they have bungled it, so I think we should disable failIfMajorPerformanceCaveat as it stands today.

Comment 20

[Pat Suwalski]

(In reply to Jeff Gilbert [:jgilbert] from comment #19)

Honestly at this point I'm tending towards #2.
Websites had the chance to handle this well and they have bungled it, so I think we should disable failIfMajorPerformanceCaveat as it stands today.

Are you suggesting PIXI doesn't handle this properly?

Comment 21

[Lee Williams]

(In reply to Jeff Gilbert [:jgilbert] from comment #18)

After bug 1680595, it should be more clear to (power) users what they can do to mitigate this.

Functionality here is, I think, working as intended now. Unfortunately the specified behavior causes certain websites (which arguably may have made poor choices) work worse for our users, whereas before things were maybe slower than they could have been, but otherwise functional.

With that in mind, since we're now following failIfMajorPerformanceCaveat spec properly, it's causing breakage. This bug is tracking the user pain-point. In order to solve the user pain-point, we might ditch failIfMajorPerformanceCaveat as accidentally-user=hostile for the time being.

Two choices:

1. Call these bad websites, and try outreach/education
2. Re-evaluate the failIfMajorPerformanceCaveat mechanism entirely

Is there a bug/explanation somewhere of what behavior changed with failIfMajorPerformanceCaveat in FF83?

Comment 22

[Mathias Panzenböck]

Call these bad websites, and try outreach/education

How do I call Google? Also since they haven't fixed it until now, I doubt they ever will. Is there some hack to make it work? An user script?

Comment 23

[web_illuminator]

Same problem on a Lenovo T530, i915 grafic controller, using via Firefox 84.0 (Ubuntur 20.04.1 LTS) tensorflow e.g with https://storage.googleapis.com/tfjs-models/demos/posenet/camera.html
Just by calling the page it tells (along with poor peformance):
Failed to create WebGL context: failIfMajorPerformanceCaveat: Compositor is not hardware-accelerated. canvas_util.ts:83:16
With Chromium browser 87.0.4280.88 , it's works as expected. It worked also nicely with older Firefox Version.

Comment 24

[Kelsey Gilbert [:jgilbert]]

(In reply to Pat Suwalski from comment #20)

(In reply to Jeff Gilbert [:jgilbert] from comment #19)

Honestly at this point I'm tending towards #2.
Websites had the chance to handle this well and they have bungled it, so I think we should disable failIfMajorPerformanceCaveat as it stands today.

Are you suggesting PIXI doesn't handle this properly?

Yes, that's what it sounds like.

Comment 25

[Kelsey Gilbert [:jgilbert]]

(In reply to panzi from comment #22)

Call these bad websites, and try outreach/education

How do I call Google? Also since they haven't fixed it until now, I doubt they ever will. Is there some hack to make it work? An user script?

That was supposed to be "call out", sorry!
Google Maps accepts feedback via the "Send feedback..." menu option.

In newer versions of Firefox, the console warning will direct you to use about:config's webgl.disable-fail-if-major-performance-caveat if you keep having issues with bad websites.

Comment 26

[Pat Suwalski]

(In reply to Jeff Gilbert [:jgilbert] from comment #24)

(In reply to Pat Suwalski from comment #20)

(In reply to Jeff Gilbert [:jgilbert] from comment #19)

Honestly at this point I'm tending towards #2.
Websites had the chance to handle this well and they have bungled it, so I think we should disable failIfMajorPerformanceCaveat as it stands today.

Are you suggesting PIXI doesn't handle this properly?

Yes, that's what it sounds like.

So what changed? If the system in question doesn't have a "major performance caveat" and the browser is reporting that it does, how is that PIXI mishandling it?

Comment 27

[Kelsey Gilbert [:jgilbert]]

The system unfortunately does (probably) have a performance caveat, because we've included "readback required for compositing" as a caveat, which is a long-time issue on Linux for us.

Comment 28

[Pat Suwalski]

I can't speak for 3D, but seeing as the 2D rendering is still loads quicker than canvas, the "performance caveat" really isn't.

What should PIXI, or any site, do with this information?

Comment 29

[Mathias Panzenböck]

(In reply to Jeff Gilbert [:jgilbert] from comment #25)

(In reply to panzi from comment #22)

Call these bad websites, and try outreach/education

How do I call Google? Also since they haven't fixed it until now, I doubt they ever will. Is there some hack to make it work? An user script?

That was supposed to be "call out", sorry!
Google Maps accepts feedback via the "Send feedback..." menu option.

In newer versions of Firefox, the console warning will direct you to use about:config's webgl.disable-fail-if-major-performance-caveat if you keep having issues with bad websites.

Thank you! Finally I have 3D maps in Firefox again! :D

Comment 30

[Kelsey Gilbert [:jgilbert]]

The goal of the WebGL Working Group was for failIfMajorPerformanceCaveat to allow websites to make better choices about which content to serve to users, ideally via offering a choice to users.

I no longer think that this is useful here, or rather it's only ever useful in the very narrow case: When a website does indeed have a fallback ready, and the fallback does actually have better perf.

Today this is only true on some Windows systems that have cpu-emulated webgl, but gpu-accelerated canvas2d, but this is not most systems.
Simultaneously, we've seen a disappointingly large set of websites break for users that hit the failIfMajorPerformanceCaveat path.

Since the usefulness of failIfMajorPerformanceCaveat is very limited, and many sites don't cooperate with us (as the user's User Agent), I think it's best to disable failIfMajorPerformanceCaveat for the time being.

Comment 32

[Kelsey Gilbert [:jgilbert]]

Attachment: Bug 1678652 - Disable failIfMajorPerformanceCaveat by default.

The goal of the WebGL Working Group was for failIfMajorPerformanceCaveat
to allow websites to make better choices about which content to serve to
users, ideally via offering a choice to users.

I no longer think that this is useful here, or rather it's only ever
useful in the very narrow case: When a website does indeed have a
fallback ready, and the fallback does actually have better perf.

Today this is only true on some Windows systems that have cpu-emulated
webgl, but gpu-accelerated canvas2d, but this is not most systems.
Simultaneously, we've seen a disappointingly large set of websites break
for users that hit the failIfMajorPerformanceCaveat path.

Since the usefulness of failIfMajorPerformanceCaveat is very limited,
and many sites don't cooperate with us (as the user's User Agent), I
think it's best to disable failIfMajorPerformanceCaveat for the time
being.

Comment 33

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/bb634a5d7268
Disable failIfMajorPerformanceCaveat by default. r=lsalzman

Comment 34

[Sandor Molnar[:smolnar]]

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

Comment 35

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

Since the status are different for nightly and release, what's the status for beta?
For more information, please visit auto_nag documentation.

Comment 36

[Ryan VanderMeulen [:RyanVM]]

Is this something we should consider uplifting to Beta for 85?

Comment 37

[Catalin Sasca, Desktop Test Engineering [:csasca]]

Reproduced the issue on Firefox 83.0 under Ubuntu 20.04 and Windows 7 by verifying google maps and low performance from the link found in Comment 23.

The 3D map works, and the performance is good for the link found in Comment 23 on Nightly 87.0a1 (2021-02-03) and Firefox 86.0b5 under Ubuntu 20.04 and Windows 7.