New issue
Advanced search Search tips

Issue 642673 link

Starred by 4 users

Issue metadata

Status: Available
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug



Sign in to add a comment

Signal backpressure when user pauses the download

Reported by ji...@warting.se, Aug 31 2016

Issue description

UserAgent: 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:
 

Comment 1 by ji...@warting.se, Aug 31 2016

cc yhirano@chromium.org
Cc: yhirano@chromium.org
Components: -Blink Blink>ServiceWorker Blink>Network>StreamsAPI Blink>Network>FetchAPI
Labels: TE-NeedsTriageHelp
Labels: -Pri-2 -OS-Mac OS-All Pri-3
Status: Available (was: Unconfirmed)
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.
Project Member

Comment 5 by sheriffbot@chromium.org, Sep 11 2017

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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

Comment 6 by ricea@chromium.org, Sep 12 2017

Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)
Project Member

Comment 7 by sheriffbot@chromium.org, Sep 12

Labels: Hotlist-Recharge-Cold
Status: Untriaged (was: Available)
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
It's still a problem
Cc: ricea@chromium.org
Labels: -Hotlist-Recharge-Cold
Status: Available (was: Untriaged)

Sign in to add a comment