User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:82.0) Gecko/20100101 Firefox/82.0

Steps to reproduce:

My addon https://addons.mozilla.org/en-US/firefox/addon/wingman-jr-filter/ leverages Tensorflow.js for neural network inference, which in turn depends on creating a WebGL context in the background.js context. FF82 worked as expected, FF83 failed to create either a "webgl" or "webgl2" context due to "failIfMajorPerformanceCaveat: Compositor is not hardware-accelerated." I have attached a minimal reproduction example that simply tries to create a WebGL context in the same way that Tensorflow.js does.

Actual results:

The WebGL context failed to create.

Expected results:

The WebGL context creation should have succeeded, as it had in FF82.

Further, I have performed a bisection and this appears to be a consequence of the fix for #1664905. I have attached both the bisection results and about:support from Firefox 82.

Bugbug thinks this bug should belong to this component, but please revert this change in case of error.

Set release status flags based on info from the regressing bug 1664905

Can you attach the about:support from 83?

I am seeing the same bug on Linux. Or at least the same error message, on maps.google.com in the console. It no longer switches to the fancy 3D map when you zoom out :(

I'll attach the about:support info.

This is the expected outcome on Linux. Without hardware compositing, contexts created with failIfMajorPerformanceCaveat will fail. If want it back you can either set webgl.disable-fail-if-major-performance-caveat=true to disable the check or gfx.webrender.all=true to turn on accelerated compositing.

I have attached the text output of about:support from Firefox 83 Portable so I can keep my installation of Firefox 82. Let me know if that is unacceptable or if you need e.g. the "raw data" output instead. Thanks!

wingman.jr.addon, do you see the same problem in the Firefox 83 Portable installation that you gave the about:support for?

Yes, I have seen consistent failure behavior from the following scenarios:

• Firefox 83 Portable with the attached minimal reproduction example
• Firefox 83 Portable with the full-fledged addon utilizing Tensorflow.js
• The original upgrade of Firefox 83 from the existing Firefox 82 installation
• Firefox 83 loaded with a new profile
• Firefox 83 loaded while also forcing GPU #2 NVIDIA GeForce 940MX to be active for Firefox via Windows 10 display settings

While I do not have hard evidence, I know from my user base that this is affecting at least 2 out of 7 users, one of which also has Win 10 with integrated graphics. Similarly, I can see from my stats that some of my users appear to have downgraded to Firefox 82 in response to my notices indicating that that is currently the workaround - implying this is likely impacting some users that have not left but have had to change their browsing experience. (Too bad because of all the other nice performance goodies in Firefox 83, by the way - thanks!)

Let me know what else I can do to help; was the mozregression output informative?

Jeff, can you take a look at this?

This sounds like the same thing as bug 1675357.

Honestly it sounds like failIfMajorPerformanceCaveat: true used to not work, and now it's working.
The minimal testcase explicitly asks for failIfMajorPerformanceCaveat: true, which if you have non-accelerated compositing, will cause context creation to fail. (by design and by spec)

The last thing I need for clarity here is a copy of about:support for 82 on a machine where it's "broken" in 83, but worked in 82.

The answer for frustrated website authors is straightforward: Don't ask for failIfMajorPerformanceCaveat: true unless you do want context creation to fail for many many users. failIfMajorPerformanceCaveat has no other use besides this "bug", so don't ask for it if you don't want this behavior.

For frustrated users, the workaround is toggling "webgl.disable-fail-if-major-performance-caveat" to "true" in about:config.

We may be able to make this better:

• Point people towards webgl.disable-fail-if-major-performance-caveat in the console warning text we generate. Moderately technical users will then be guided towards the proper workaround this issue for themselves and others.
• Add a checkbox to the Firefox Settings pages to allow users to tell us how to handle this

@ken needinfo for FYI

Wingman, can you get us a copy of about:support for 82 on a machine where it's "broken" in 83, but worked in 82?

:jgilbert: I believe the already attached about_support_ff82.txt is what you're looking for. Let me know if you need something more. Thanks for looking into this.

jgilbert, In both ff82 and ff83 accelerated compositing appears enabled and webgl context creation is still failing.

Thanks for the heads up. failIfMajorPerformanceCaveat was added specifically for applications that support other fallbacks (such as if WebGL's software rasterized, use 2D canvas instead - like Google Maps). Warnings in the console to this end sound fine.

Ohh, we're probably not recognizing Advanced Layers.

Here's a jsfiddle: https://jsfiddle.net/Lb368nh7/

FYI, that successfully creates a WebGL context on a dual-GPU MacBook Pro with Firefox Nightly 85.0a1 (2020-12-04) (64-bit).

I suspect it generally works but that our bug here is that it doesn't work with "Advanced Layers", which is one of our Windows-only backends, coincidentally soon-to-be-removed! This would be S4 to me.

Don't we want to fix that for 84?

As an observation of perhaps some interest, the JS Fiddle https://jsfiddle.net/Lb368nh7/ seems to succeed for me even on FF83 as I don't see the error message. However, the minimal reproduction example fails, leading me to wonder if it is perhaps a change specifically in how WebExtensions is handling things.

It wasn't clear to me if the patch by jgilbert was in the 85.0a1 2020-12-04 nightly, but I did some testing as if it were. Here is the summary:

• 85.0a1 Nightly + JS Fiddle = Success
• 85.0a1 Nightly + Minimal Repro = Failure
• FF83 Portable + JS Fiddle = Success
• And from before, FF83 Portable + Minimal Repro = Failure

I will be attaching screenshots in case I've misinterpreted something so that the results are clear.
Thanks for looking into this!

I'm also experiencing this problem.
The jsfiddle also gives me the same error.
(first noticed it when trying to use https://demo.f4map.com/ and getting an error both on screen and in the console about opengl not working)
Firefox 83.0
Operating System: Manjaro Linux
KDE Plasma Version: 5.20.4
KDE Frameworks Version: 5.77.0
Qt Version: 5.15.2
Kernel Version: 5.9.11-3-MANJARO
OS Type: 64-bit
Processors: 16 × AMD Ryzen 7 3700X 8-Core Processor
Memory: 31,3 GiB of RAM

For Linux see https://bugzilla.mozilla.org/show_bug.cgi?id=1679671#c14
This is working as intended there, and an user issues are with the website not the browser.

I mean fixing it in 84 for Windows.

I have reproduced the issue with the addon, where failIfMajorPerformanceCaveat:true causes context creation failure when requested from a background script, even while the jsfiddle shows no issue. I suspect that background scripts aren't connected to Layers, though I'm not really sure what to do here. I don't know if we can really guarantee that the background script gets the same failIfMajorPerformanceCaveat result as content scripts, but maybe we should have some "headless caller" concept here.

The workaround here is "don't use failIfMajorPerformanceCaveat:true in background scripts", but this is not a priority to fix.

I'll split off the other aspect (IPC_FAIL) into another bug to let us focus on this here.

Comment on attachment 9191445 [details]
Bug 1679671 - Don't IPC_FAIL for context creation failure.

Revision D98835 was moved to bug 1681147. Setting attachment 9191445 [details] to obsolete.

Ok, well thank you team for examining this issue. Based on the change in the title, it sounds like this will basically happen all the time now for anything in background.js. @jgilbert is this more of a cosmetic issue where the failIfMajorPerformanceCaveat flag is reporting incorrectly, or are you indicating with the comment that you suspect "background scripts aren't connected to Layers" that there is likely a true performance issue (such that I might have better luck moving processing to a content script somehow instead)?
Again - thanks for taking the time to look into this.

Background Scripts aren't connected to Layers, I'm pretty sure: There's isn't a way to "view" them in a window. They should still classify e.g software-webgl as a caveat, but not having accelerated layers shouldn't matter to Background Scripts. Unfortunately there's no disambiguation between these cases.

I would say though that anything that doesn't work at all when failIfMajorPerformanceCaveat is true represents a bug in that content. Addons should still function even if e.g. hardware acceleration is disabled, albeit with reduced performance.

Thanks - I'll assume it'll probably work then but that I may be able to get a performance boost by doing a different method. Thanks for the feedback!

I'm also affected, for my extension https://addons.mozilla.org/en-US/firefox/addon/colorify/
Since the update, the performance is horrendous when using deep-learning mode, which uses tensorflow.js