Affected versions

• Firefox 77.0
• Firefox 78.0a1

Affected platforms

• macOS 10.15
• Windows 7
• Ubuntu 18.04

Steps to reproduce

1. Launch Firefox
2. Access an article from The Verge, for example and scroll down to where the video is located
3. Click on play

Expected result

• The video is played without issues

Actual result

• The video is not played back

Regression range

• Will see for a regression, it seems that 68.9.0esr is not affected

Additional notes

• The issue can be seen in the following attachment

Turn off ETP on this website and the video will work.

S1 or S2 bugs need an assignee - could you find someone for this bug?

The Twitter video is embedded in the iframe: https://twitter.com/i/videos/tweet/1265444495488880649?embed_source=clientlib&player_id=0&rpc_init=1&autoplay=1&language_code=en&use_syndication_guest_id=true. Since twitter.com is on the blocklist, this iframe does not have storage access.

This iframe embeds the script: https://abs.twimg.com/web-video-player/TwitterVideoPlayerIframe.cefd459559024bfb.js which does the following storage access checks:

        f = function() {
            var e = d && window.indexedDB || "undefined" != typeof self && self.indexedDB;
            if (e && d) try {
                window.localStorage.setItem("test", "a"), window.localStorage.removeItem("test")
            } catch (e) {
                return !1
            }
            return e
        },

When window.indexedDB is accessed, an uncaught SecurityError is thrown and the video never loads.

Uncaught DOMException: The operation is insecure. TwitterVideoPlayerIframe.cefd459559024bfb.js:76

This is unfortunate because the code here is clearly trying to test whether it has access to window.indexedDB (which it doesn't) and then fall back to local storage (which will also throw a security error). If Twitter were to include indexedDB in the try-catch the video would likely load.

We also have a few options on our end. If scripts do indeed expect window.indexedDB to be null instead of throw a SecurityError, that might be a better approach.

Alternatively, we can consider adding something similar to isolated localStorage.

Mike, do you know if we have contacts at Twitter who can help?

Hi, I tried to get a regression range for this issue and I went back as far as I could, but it seems between the 2018-09-01 and 2018-08-31 there was not enough data to bisect.
Here are the pushlogs from the Last known good build and the First known bad build, I was unable to pin point the issue causing it but maybe it helps someone who knows more about it:

First known bad
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ea869706644d3b2354b2438c77671d6e43df5e99&tochange=8284cddccf78566ca4dc45272940ccae4b1150df

Last known good
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ea869706644d3b2354b2438c77671d6e43df5e99&tochange=d14aaf65a80b3baddb193fa6707e4515e4a44609

This also reproduces on https://www.nytimes.com/2020/05/28/us/george-floyd-national-guard.html. I suspect this happens with all embedded Twitter videos.

We've shipped a skiplist intervention (Bug 1641969) and are planning to migrate to a webcompat intervention (Bug 1641998).

I sent an email to our internal Mozilla/Twitter list.

I've verified that this is now fixed in Nightly 80 and Release 78.