UserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.77 Safari/537.36

Steps to reproduce the problem:
This is a regression that was introduced with the latest minor version bump to 70.0.3538.110 (see attached screen shots). The problem does neither occur on older minor Chrome versions such as 70.0.3538.102, not on Chrome Canary.

1. Go to https://app.clipchamp.com and sign up (free)
2. Click "Add Media" (top-left), then click the "Browse library" (right side)
3. Open the Chrome dev tools (console view)
4. Select and pick any video from the stock video libary (drill down into one of the stock video collections, hover with the mouse over a particular video, then click the purple (+) button in the top-left corner of that video) - you can add multiple videos here
5. Click the purple (x Close Library) button in the top-right corner
6. The JS console will show heaps of "net::ERR_REQUEST_RANGE_NOT_SATISFIABLE" issues AND these requests do not return the correct response body

BACKGROUND: Clipchamp uses a Service Worker to intercept GET requests to "https://app.clipchamp.com/local-cache/..." URLs. These URLs point to media files that we locally cache in IndexedDB ("local-cache" database, "assets" object store). Our service worker implements HTTP Range requests, retrieving the Blob instances from IndexedDB and slicing out the right partial response (HTTP/206), which is then sent back (fetchEvent.respondWith(...)) to the app as an HTTP/206 partial response. 

Since the latest minor version bump, we are are experiencing that the Response instance that is returned from the service worker gets corrupted. We have extensively debugged our service worker implementation and also confirmed that the media files are correctly stored and retrieved from IndexedDB. Hence we assume that the culprit is somewhere in Chrome's network stack or service worker implementation and is indeed a regression.

Please note that this does currently break our app completely and is a major disruption for our users and ultimately our business. We rely on the Chrome team to be fast to address and fix this issue. We have tried various workarounds - but so far to no avail. 

What is the expected behavior?
Response objects that are sent back from the service worker should not be corrupted. 

What went wrong?
The service worker or network stack seems to corrupt these synthetic Response objects that we create. Attaching screen shots from the JS console when running our app - one from version 70.0.3538.110 with the issue and one from version 70.0.3538.102 without. We see the issue on Mac and Windows (still to confirm it exists on Linux as well). 

Did this work before? Yes 70.0.3538.102

Does this work in other browsers? Yes

Chrome version: 70.0.3538.110  Channel: stable
OS Version: 10.14.1
Flash Version: 

Please reach out to me if you require any clarifications or assistance in getting this issue reproduced. This is a high-impact issue for our business.
 

Deleted: Version 70.0.3538.110 doesn't work.png 1.0 MB

	Version 70.0.3538.110 doesn't work.png 1.0 MB View Download

Deleted: Version 70.0.3538.102 works fine.png 1.4 MB

	Version 70.0.3538.102 works fine.png 1.4 MB View Download