I suspect this bug is a regression from sanitized UNMASKED_RENDERER bug 1722113.

Steps to reproduce

1. In Firefox Nightly 92, open https://mozilla.cultureamp.com/app/skills-coach/activity/24A1EEE41AABFBB870F72F2158667007247B949C55FF00CF04763E31107927179D361EFBEF9564132177D6004A8122CF
2. Click the "Next" button four times to reach the "Get some practice naming the need" screen.

Expected result

The video should have a play button, like in Firefox 90 and 91.

Actual result

The video is blurry and has no play button. See the attached screenshot.

I see the following error about UNMASKED_RENDERER_WEBGL in the web console:

Uncaught (in promise) TypeError: can't access property "UNMASKED_RENDERER_WEBGL", i is null
    pt https://fast.wistia.net/assets/external/E-v1.js:2
    pt https://fast.wistia.net/assets/external/E-v1.js:2
    M https://fast.wistia.net/assets/external/E-v1.js:2
    value https://fast.wistia.net/assets/external/E-v1.js:2
    value https://fast.wistia.net/assets/external/E-v1.js:2
    shouldMount https://fast.wistia.net/assets/external/E-v1.js:2
    d https://fast.wistia.net/assets/external/E-v1.js:2
    value https://fast.wistia.net/assets/external/E-v1.js:2
    lastRenderPromise https://fast.wistia.net/assets/external/E-v1.js:2
    value https://fast.wistia.net/assets/external/E-v1.js:2
    value https://fast.wistia.net/assets/external/E-v1.js:2

Hmm, did no one use this site with resist-fingerprinting enabled? That's basically what the new behavior is.

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

Hmm, did no one use this site with resist-fingerprinting enabled? That's basically what the new behavior is.

I don't use resistFingerprinting, but I just confirmed that this video is indeed broken in Firefox 90 with resistFingerprinting.

If this is a problem that Culture Amp should fix on their site, we probably have technical support contacts there because Mozilla is a Culture Amp customer.

Finding this so quickly after landing the change probably indicates that this won't be an isolated compat issue, and that more care is required. While the current state is what I'd like to get to, we can take a more gradual approach.

https://hg.mozilla.org/mozilla-central/rev/52689741f6de

This reverted the breaking change, so no documentation needed here.

The deprecation of WEBGL_debug_renderer_info is not documented on MDN. The warning added in this bug already caused an stackoverflow post.

Docs issue got posted in https://github.com/mdn/content/issues/12689

Can you confirm the actual change. It looks to me like in version 92 you first removed set webgl.enable-debug-renderer-info false, then in this bug set it back to true but with a deprecation warning. What is the reason for this deprecation? Is this related to the spec?

The reason that it affects how I'd update the browser compatibility data.

(In reply to Hamish Willee from comment #9)

Can you confirm the actual change. It looks to me like in version 92 you first removed set webgl.enable-debug-renderer-info false, then in this bug set it back to true but with a deprecation warning. What is the reason for this deprecation? Is this related to the spec?

WEBGL_debug_renderer_info exposes unique system information that can be used to fingerprint users. I believe the hope in bug 1722113 was that legitimate web content did not rely on WEBGL_debug_renderer_info, so we could unship the API. However, this bug is one example of legitimate web content that was broken.

I don't know if Kelsey still has plans to unship WEBGL_debug_renderer_info or reduce the fingerprinting entropy the API exposes.

Thanks very much Chris. A bit odd for me - usually specs get updated and then changes like this happen.

I've created a BCD entry for this here: https://github.com/mdn/browser-compat-data/pull/14964