What did you do? ================ 1. create an html page with this video tag: <video src="https://s3.amazonaws.com/bloomberg-vod-prod-us-east1/m/NzU3NjQ0NA/MjUxNTc4NA/surv071918_1800.mp4" controls></video> 2. Create another version that registers a simple service worker that routes all requests through the fetch API (I did so using Angular 6 for ease but this will happen with any service worker implementation that goes through the fetch api) 3. load both pages and hit play and then seek to the middle of the video on both versions What happened? ============== 1. On the fetched version, the seek caused the entire video up to that point to reload 2. the fetched version cut off the content-range headers and different content-length headers 3. the fetched version takes longer to begin playback 4. the fetched version gave 200 responses instead of 206 5. Basically, the fetch doesn't know how to handle properly partially fetching media What should have happened? ========================== The 2 media downloads should be identical Is there anything else we should know? ====================================== I can provide a full repro if needed. This is problematic for sites that want the benefits of service workers and want to consider using them to preload media content

bryan.duva - What Firefox version are you using? I think a full example would be useful for debugging.

I'm on latest firefox (61.0.1), worth noting that the same behavior appears in every browser I've tested (chrome, opera, edge, firefox). I'm out of my depth on browser internals and what is underlying them all that could cause this issue in every browser. But, you can go to: https://s3.amazonaws.com/fetch-bug-no-worker/index.html To see the video behaving properly (no worker, just the video tag) https://s3.amazonaws.com/fetch-bug-with-worker/index.htmlt going through the video) and to: https://s3.amazonaws.com/fetch-bug-with-worker/index.html to see it misbehaving. (you may need to reload the page because the super simple worker isn't intercepting video requests on first install for some reason and I'm not gona invest time into debugging it). In both pages, inspect the network requests and try seeking to the middle of the video. The standard version performs very well, regardless of seek position the video starts shortly thereafter. The worker intercepted version is unusable as it tries to reload the entire video up to the seeked point on seek.

Tested & reproducible on: 61.0.1 20180704003137, 62.0b10 20180719140244 and 63.0a1 20180724100052. Looking around I've also found a range fetch demo that is broken on Firefox and at first glance seems related to this issue: https://simpl.info/video/range/ Not entirely sure what to make of this bug so far, but I'd guess this should be somewhere in networking? Valentin, can you please take a look?

Anne, I assume this is the object of the note regarding Range requests at [1] and the reverenced issue at [2]. Can you advise how we should proceed here? [1] https://fetch.spec.whatwg.org/#privileged-no-cors-request-header-name [2] https://github.com/whatwg/html/pull/2814

We should fix bug 1465074.