1919592 - Apple support videos not playing in Desktop Firefox

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P2)

Description

[Jim Mathies [:jimm]]

Related to Bug 1912873 - apple.com - Video from support page does not play

Comment 1

[Jim Mathies [:jimm]]

https://share.firefox.dev/4e9FWoE

Comment 2

[Jim Mathies [:jimm]]

with logging -
https://share.firefox.dev/3TzsEJM

Comment 3

[Dan Baker[:dbaker]]

I see this error in the console:

"Content-Security-Policy: The page’s settings blocked a worker script (worker-src) at blob:https://support.apple.com/76c9bf0a-f005-4d8a-91b8-5f5d7f8bfd93 from being executed because it violates the following directive: “child-src 'self' https://support.apple.com https://apple.com https://km.support.apple.com”"

As a test I forced permitted to true here https://searchfox.org/mozilla-central/source/dom/security/nsCSPContext.cpp#172 and the video plays.

Chrome seems to have a similar error but mention a fallback :

"https://support.apple.com/15bfa2b5-d33b-4695-8e5a-d7f130127488' because it violates the following Content Security Policy directive: "child-src 'self' support.apple.com apple.com km.support.apple.com". Note that 'worker-src' was not explicitly set, so 'child-src' is used as a fallback."

Comment 4

[Alastor Wu [:alwu]]

The observation in comment3 seems reasonable to me, Apple uses MSE for that video, but they don't append any data into the MSE source buffer, which apparently was blocked by CSP. This issue is a network issue, move this to another component.

Comment 5

[Daniel Veditz [:dveditz]]

(In reply to Dan Baker[:dbaker] from comment #3)

Chrome seems to have a similar error but mention a fallback :

Firefox has exactly the same fallback, but our message is less explicit than Chrome's. You can see we are looking to enforce "worker-src" on the resource, but are actually enforcing the rule found in in the fallback "child-src" directive.

The fallbacks are defined at https://w3c.github.io/webappsec-csp/#request-effective-directive

In both Chrome and Firefox Pf = new Worker(r); is failing due to CSP. In Chrome that throws an exception which skips over all the code below and jumps to the catch (e) { throw new Error('Failed to create WebWorker') }. Firefox doesn't throw, and the video doesn't load. Presumably whatever catches the error after that compensates for the failed worker, but I think we have our culprit here so I didn't confirm that. This is the point where Chrome and Firefox diverge: not in whether the CSP rule enforcement is correct, but what new Worker() does on CSP failure.

      try {
        if (null == Pf) {
          const e = new Blob(
            ['var exports = {};var module = { exports: exports };function define(f){f()};define.amd = true;(' + Xy.toString() + ')(true);'],
            {
              type: 'text/javascript'
            }
          ),
          r = URL.createObjectURL(e);
          Pf = new Worker(r)
        }
        var t = new lt(Pf);
        return i = t,
        n = e.child({
          name: 'WorkerRPCService'
        }),
        i.register(
          'logger.log',
          (e, i, ...r) => t => {
            try {
              for (const i of e) n = n.child(i);
              'function' == typeof n[i] &&
              n[i](...r),
              t()
            } catch (e) {
              t(void 0, e)
            }
          }
        ),
        t
      } catch (e) {
        throw new Error('Failed to create WebWorker')
      }

A CSP blocked resource is supposed to act like a network load failure. Is CSP doing something wrong that's specific to worker, or is new Worker() doing the wrong thing generally with load failures? Or doing a "different from Chrome" thing, at least.

In Safari I don't see a CSP error, but it also doesn't load the script that triggered the error: https://support.apple.com/etc/designs/support/publish/commons-sk7/ac-assets/ac-toolkit/ac-video/libs/hls/hls.js

Comment 6

[Daniel Veditz [:dveditz]]

If I open the dev tools console on the iphone URL here and paste the following:

 try { x = new Worker("https://www.google.com") } catch(e) { console.log("caught", e) } 

On Safari and Chrome I catch a SecurityError (it's not same origin). In Firefox I see a SecurityError on the console, but I can't catch it.

The HTML spec mentions throwing a SyntaxError for an invalid URL, but not any others. There's a note that it has to be same origin, but nothing about what to do if it's not: https://html.spec.whatwg.org/multipage/workers.html#dom-worker

The MDN documentation mentions the SyntaxError above, the SecurityError when it's not same-origin, and a NetworkError if it's the wrong MIME type: https://developer.mozilla.org/en-US/docs/Web/API/Worker/Worker

I do get a failure when I try to load a same-origin image as a worker in all three browsers. Chrome and Firefox display error messages about the MIME type in the console while Safari does not, but none of them throw an error.

CSP blocking the blob: url is correct. While the browser otherwise treats it as same-origin with hosts listed in the directive, CSP requires an explicit listing of blob: before it can be used because it carries similar risks to eval().

Comment 7

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Daniel Veditz [:dveditz] from comment #6)

If I open the dev tools console on the iphone URL here and paste the following:

 try { x = new Worker("https://www.google.com") } catch(e) { console.log("caught", e) } 

On Safari and Chrome I catch a SecurityError (it's not same origin). In Firefox I see a SecurityError on the console, but I can't catch it.

The HTML spec mentions throwing a SyntaxError for an invalid URL, but not any others. There's a note that it has to be same origin, but nothing about what to do if it's not: https://html.spec.whatwg.org/multipage/workers.html#dom-worker

This is discussed in https://github.com/whatwg/html/issues/9794 and https://github.com/web-platform-tests/wpt/issues/41745 with https://github.com/whatwg/html/pull/9668 removing the spec language that allowed synchronously throwing a SecurityError.

I believe the tl;dr is:

• Eden filed in https://github.com/whatwg/html/issues/9794 how Blink and Webkit synchronously throws but Firefox asynchronously generates the error and how both paths were seemingly allowed but this leads to webcompat problems.
• It was closed in favor of the already open https://github.com/web-platform-tests/wpt/issues/41745 where I think there was consensus that only the asynchronous SecurityError behavior was supported by spec and https://github.com/whatwg/html/pull/9668 made the spec consistent on this front.
• A Blink engineer indicated Blink was unlikely to change this anytime soon in Nov 2023 and it seems like other browsers haven't moved to change their implementations, it would seem.

I just pinged on that issue 41745 mentioning this bug to see if there's likely to be any changes in the future. I assume we will probably need to change our implementation and the spec.

Comment 8

[Andrew Sutherland [:asuth] (he/him)]

(In reply to Andrew Sutherland [:asuth] (he/him) from comment #7)

I just pinged on that issue 41745 mentioning this bug to see if there's likely to be any changes in the future. I assume we will probably need to change our implementation and the spec.

:annevk did chime in yesterday, but it does not look like we're likely to get any changes from other browsers in the short term so we might as well change to conform to what the other browsers are doing.

Assigning to myself for an initial implementation attempt.

Comment 9

[Andrew Sutherland [:asuth] (he/him)]

:denschub, do you know where we are are on the contact status for this or if we need more help finding a contact point?

In the github issue discussion, the editor of the fetch spec (:annevk) replied to my new comment yesterday and is concerned about specifying even further deviations from the fetch spec that this would entail since CSP validation is a step beyond what the spec previously allowed. (Although based on comment 5, at least Chrome/Blink is already doing this.) As :annevk does work at Apple on webkit, he may be able to help us find someone to talk to from the Apple support site team.

Comment 10

[Karl Dubost💡 :karlcow]

I will open a bug on Apple side. Thanks a lot everyone for the diagnosis. This is super useful.

Comment 11

[Dennis Schubert [:denschub]]

Thank you, Karl!

Comment 12

[Karl Dubost💡 :karlcow]

tracked at Apple by rdar://137744381

Comment 13

[Andrew Sutherland [:asuth] (he/him)]

Eden has indicated he is working on a fix for this in bug 1471805 so to reduce confusion I'm making him the assignee.

Comment 14

[James Graham [:jgraham]]

This is basically just a site report and we have another bug for the core platform issue, so I'm moving this to the site reports component.

Comment 15

[Eden Chuang[:edenchuang]]

This is a Web Compatibility issue and also not a Web Compatibility issue.

I want to emphasize that the synchronous throwing does not follow the current spec.
Firefox indeed implements the spec, but other browsers do not.
So, I think Firefox is compatible with spec but not with other browsers.

Firefox gets many complaints from web developers about the different behaviors.
To fix this special Web Compatibility issue, we decided first to implement synchronous throwing to give web developers the same experience as other browsers and then update the spec to synchronous throwing.

I am developing the patch in bug 1471805 and would not cause me more than 6 weeks of work.

Comment 16

[Andrew Sutherland [:asuth] (he/him)]

Based on https://bugzilla.mozilla.org/show_bug.cgi?id=1912873#c10 and the subsequent comment we believe this has been addressed by Apple making fixes and this allows us to retain our spec-compliant behavior which is the direction we want the spec to remain/go.