1637325 - Service Worker Fails Request For Video

Status: NEW

(Core :: DOM: Service Workers, defect, P3)

Description

[ebrisco]

Attachment: ff_bug_report.zip

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

Steps to reproduce:

Attached is a demo application which includes:

• A simple Service Worker that uses fetch to answer requests
• A sample video
• A web page that repeatedly plays the video

Because the demo uses a Service Worker it must be run over HTTPS.

Actual results:

As the video repeatedly plays, the JavaScript console will also log this error repeatedly:

Failed to load ‘… v.mp4 …’. A ServiceWorker intercepted the request and encountered an unexpected error.

I am not sure what the error is and I do not know how to get any additional information about this error.

The video continues playing despite this error.

Expected results:

The Service Worker should not encounter an error responding to the request for the video.

This may seem benign because the video continues to play. However, it seems the Service Worker is not actually delivering the video response to the web page, and so if an application relies on Service Workers for proper function (such as caching or URL rewriting) then this is an issue.

Comment 1

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

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

Comment 2

[Rachel Tublitz [:rachel]]

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

Comment 3

[Travis Everett]

I think we may have run into this issue as well.

We deployed a fairly simple service worker a week ago and all had seemed OK on our side until we received two end-user reports yesterday about (mp4) videos abruptly terminating early in FF (in a way that is triggering the "ended" event and causing the player to advance suddenly to the next video in the queue).

Here's a boiled-down version of the worker (registered with scope /):

self.addEventListener('fetch', function(event) {
  if (/* event.request.url is interesting */){
    event.respondWith(fetch(event.request).then(function(res){
      try {
        clients.get(event.clientId).then(function(client){
          if (!client) return
          // post message to client if specific header is present
        });
      } catch(err) {
        console.log("Error fetching resource from service worker", err)
      }
      return res
    }));
  }
});

We see the same error messages reported by the reporter, but they don't seem to trigger consistently (and the videos don't always end early even when one occurs), so we had a little trouble running it to ground. I did ultimately reproduce the behavior our users described on macOS in in FF 77.0.1 and 78.0b8, and a colleague was able to identify behavior that we think may be the same issue (but manifesting a little differently) on Windows 10 in FF 77.0.1.

In our case, the videos are hosted on a CDN subdomain backed by CloudFront, and I think we'll be able to work-around/mitigate the issue by updating the service worker to exclude the CDN in the first if statement above. (I was able to reproduce the issue locally before making this change, and have been unable to reproduce it after making this change--but we've had enough trouble triggering the issue consistently that it's hard to be certain.) I've deployed this change this evening, and will update in coming days if this doesn't ultimately work out.

In addition to the error message reported by the reporter, we noticed a number of things in the Network tab of Developer Tools that were closely correlated with this behavior:

• "normal" requests that play through cleanly:
  • return 206 Partial Content
  • use http/2
  • report an actual file size in the Transferred column
  • report different start and end times which reflect how long the download took
  • total network transfer reported in status bar includes two near-identical numbers, with the first value slightly smaller than the second
• requests which trigger the error message and skip behavior:
  • return 200 OK
  • use http/1.1
  • report "service worker" in the transferred column
  • report identical start and end times
  • total network transfer reported in status bar includes a first value substantially (10-15%?) larger than the second

We've saved multiple HARs and console log copies from playing a fixed set of videos (both when it was and wasn't exhibiting this behavior, with and without the workaround) if you think they'll help, though I'm not particularly comfortable posting them in public.

Comment 4

[Perry Jiang [:perry] [no longer employee, use ni?]]

(In reply to ebrisco from comment #0)

Created attachment 9147677 [details]
ff_bug_report.zip

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

Steps to reproduce:

Attached is a demo application which includes:

• A simple Service Worker that uses fetch to answer requests
• A sample video
• A web page that repeatedly plays the video

Because the demo uses a Service Worker it must be run over HTTPS.

Actual results:

As the video repeatedly plays, the JavaScript console will also log this error repeatedly:

Failed to load ‘… v.mp4 …’. A ServiceWorker intercepted the request and encountered an unexpected error.

I am not sure what the error is and I do not know how to get any additional information about this error.

The video continues playing despite this error.

Expected results:

The Service Worker should not encounter an error responding to the request for the video.

This may seem benign because the video continues to play. However, it seems the Service Worker is not actually delivering the video response to the web page, and so if an application relies on Service Workers for proper function (such as caching or URL rewriting) then this is an issue.

Are you still able to consistently reproduce the issue? I tried on both 76.0 and 78.0 and didn't have any luck.

(In reply to Travis Everett from comment #3)

I think we may have run into this issue as well.

We deployed a fairly simple service worker a week ago and all had seemed OK on our side until we received two end-user reports yesterday about (mp4) videos abruptly terminating early in FF (in a way that is triggering the "ended" event and causing the player to advance suddenly to the next video in the queue).

Here's a boiled-down version of the worker (registered with scope /):

self.addEventListener('fetch', function(event) {
  if (/* event.request.url is interesting */){
    event.respondWith(fetch(event.request).then(function(res){
      try {
        clients.get(event.clientId).then(function(client){
          if (!client) return
          // post message to client if specific header is present
        });
      } catch(err) {
        console.log("Error fetching resource from service worker", err)
      }
      return res
    }));
  }
});

We see the same error messages reported by the reporter, but they don't seem to trigger consistently (and the videos don't always end early even when one occurs), so we had a little trouble running it to ground. I did ultimately reproduce the behavior our users described on macOS in in FF 77.0.1 and 78.0b8, and a colleague was able to identify behavior that we think may be the same issue (but manifesting a little differently) on Windows 10 in FF 77.0.1.

In our case, the videos are hosted on a CDN subdomain backed by CloudFront, and I think we'll be able to work-around/mitigate the issue by updating the service worker to exclude the CDN in the first if statement above. (I was able to reproduce the issue locally before making this change, and have been unable to reproduce it after making this change--but we've had enough trouble triggering the issue consistently that it's hard to be certain.) I've deployed this change this evening, and will update in coming days if this doesn't ultimately work out.

In addition to the error message reported by the reporter, we noticed a number of things in the Network tab of Developer Tools that were closely correlated with this behavior:

• "normal" requests that play through cleanly:
  • return 206 Partial Content
  • use http/2
  • report an actual file size in the Transferred column
  • report different start and end times which reflect how long the download took
  • total network transfer reported in status bar includes two near-identical numbers, with the first value slightly smaller than the second
• requests which trigger the error message and skip behavior:
  • return 200 OK
  • use http/1.1
  • report "service worker" in the transferred column
  • report identical start and end times
  • total network transfer reported in status bar includes a first value substantially (10-15%?) larger than the second

We've saved multiple HARs and console log copies from playing a fixed set of videos (both when it was and wasn't exhibiting this behavior, with and without the workaround) if you think they'll help, though I'm not particularly comfortable posting them in public.

If you are comfortable emailing any useful info to me at [e-mail] I'd be happy to take a look.

Comment 5

[Travis Everett]

Sure. I think I still have the HARs in a folder. I'll be in touch soon.

Comment 6

[ebrisco]

The issue seems to be that FireFox is eventually not requesting the video using the src of the video tag, but rather the final redirected URL.

So, there is a video tag created with src=https://a/video.mp4
FireFox sends a request to the ServiceWorker for https://a/video.mp4 as expected
The ServiceWorker follows an HTTP redirect to https://b/video.mp4
The ServiceWorker returns the response

This works a few times, but then eventually FireFox starts requesting https://b/video.mp4 directly, even with the src is https://a/video.mp4

This is a problem because the ServiceWorker does special work based on the original URL, not the final redirected URL.

Sorry I don't have an executable example for you.

Comment 7

[Travis Everett]

(In reply to ebrisco from comment #6)

The issue seems to be that FireFox is eventually not requesting the video using the src of the video tag, but rather the final redirected URL.
...
This works a few times, but then eventually FireFox starts requesting https://b/video.mp4 directly, even with the src is https://a/video.mp4

This explanation does appear to square with our case. The initial src added to the video points to a server endpoint that returns a redirect to a signed link on the CDN.

Comment 8

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

A few questions:

• How is fetch being invoked in the ServiceWorker?
  • Is it a pass-through fetch (event.respondWith(fetch(event.request)))?
  • If not pass-through, what are the mode and redirect (mode) arguments provided to fetch?
    • Is origin B properly enabled so that a CORS-check passes if the fetch request mode is "cors"?
• Is the ServiceWorker returning the response from origin B with the origin B URL still on the Response (response.url), or is the content being re-badged via a new Response to have a claimed URL of origin A? When a ServiceWorker invokes respondWith(), if the URL of the Response is not the same as the URL of the Request, from the page's perspective it's the same as if a redirect was followed to arrive at the Response's URL. (And I see in our media code that at least some code does intentionally use post-redirect URL's, although I can't speak to whether that's spec appropriate and would need to ask others or do more reading.)
• Does the same general network flow happen when ServiceWorkers aren't used, and if so, is similar behavior witnessed there as well?

Comment 9

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

Also, please send any HAR logs that you want to send, if you want to send them, to [e-mail] from here on out.

Comment 10

[ivan.zderadicka]

I'm getting similar error on FF 97.0 on Ubuntu.

Message is:

Failed to load ‘’. A ServiceWorker intercepted the request and encountered an unexpected error.

Appears only with requests from AUDIO element (after setting src to given URL).

For sure there is no redirection on my side, serving directly. Couple more observation:

• content is audio/ogg or audio/mpeg with opus codec
• if serving from CacheStorage, then url is empty as shown above. If serving from fetch request then message contains actual URL
• I'm experiencing on local machine during development - so http://localhost and actual audio files are served from different port that the page
• Chromium is OK - no errors or warnings

Comment 11

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

The bug has a release status flag that shows some version of Firefox is affected, thus it will be considered confirmed.