Closes #9354 improve resume downloads in slow networks #9036
Conversation
Amejia481
force-pushed
the
issue-9033
branch
from
62ebe96 to
81e3244
Compare
| // networks start a download but quickly press pause and then resume | ||
| // [isResumingDownload] will be false as there will be not enough time | ||
| // for bytes to be copied, but the stream in [download.response] will be closed, | ||
| // we have to fallback to [httpClient] |
There was a problem hiding this comment.
Currently this logic would also be applied for downloads already using the HTTP client. I think in this case we don't need to fall back and we don't need to call performDownload again as we're already using the same client anyway. I think we should check for that here...only fall back to the fetch client if we're not already using it.
There was a problem hiding this comment.
I also think it's worth filing this for GV to potentially improve the API.
There was a problem hiding this comment.
Currently this logic would also be applied for downloads already using the HTTP client. I think in this case we don't need to fall back and we don't need to call performDownload again as we're already using the same client anyway. I think we should check for that here...only fall back to the fetch client if we're not already using it.
👍🏽
I also think it's worth filing this for GV to potentially improve the API.
👍🏽
Thanks, I will update it with the correct one :) |
Amejia481
force-pushed
the
issue-9033
branch
from
81e3244 to
fa9caeb
Compare
|
I filed https://bugzilla.mozilla.org/show_bug.cgi?id=1679852 for it. |
Amejia481
added
🛬 needs landing
In cases where users with slow networks start a download but quickly press pause and then resume, there will be not enough time for bytes to be copied, but the stream in [download.response] will be closed, and when the user will retry we will try to use [download.response] over and over with a closed stream as a result the download will failed every time, we have to fallback to httpClient
Pull Request checklist
After merge