Signal backpressure when user pauses the download
Reported by
ji...@warting.se,
Aug 31 2016
|
||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/52.0.2743.82 Safari/537.36 Steps to reproduce the problem: (This is done inside a service worker) 1. Intercept a link and respondWith() a custom response 2. The custom response should have a readable stream and a Content-Disposition header to trigger a download 3. Pause the download in the browsers UI 4. Enqueue some chunks to the readable stream after you have paused the download This can also be tested here: https://jimmywarting.github.io/StreamSaver.js/example.html 1. Choose plain text 2. Write a couple aaa's to trigger the download dialog to appear and save it somewhere 3. Pause the download 4. Write a lot of Lorem ipsum (100 MiB or so) 5. Resume the download What is the expected behavior? The ReadableStream in the service worker would stop pulling for more data and that the desiredSize in the stream controller goes to 0 I expected it to stop pulling What went wrong? The ReadableStream keeps pulling for more data even doe client paused the download. (The desiredSize in the stream controller is always positive) Did this work before? No Chrome version: 52.0.2743.82 Channel: stable OS Version: OS X 10.11.5 Flash Version:
,
Aug 31 2016
,
Sep 1 2016
,
Sep 9 2016
Thanks for the test case! It looks like there is indeed a bug here. The SW seems to write data to the stream response without bound even though no one is consuming it. I wrote several GB of lorem ipsum and witnessed enqueue() being called continuously. When the download is resumed, it immediately fails with network error. However I couldn't get an OOM crash or anything. Since pausing the download is a niche use case, setting Pri-3.
,
Sep 11 2017
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 12 2017
,
Sep 12
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Sep 12
It's still a problem
,
Sep 12
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by ji...@warting.se
, Aug 31 2016