1819001 - [Downloads v2] download can not resume

Status: UNCONFIRMED

(Firefox for Android :: Downloads, defect, P3)

Description

[xl19870217]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.69 Safari/537.36

Steps to reproduce:

pause downlaod status, then resume downlad file. it will failed.
https://romspure.cc/download/metal-gear-solid-3-snake-eater-16042/2
it is well when i use chrome browser.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:cpeterson, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 2

[Alexandra Virvara]

The described problem doesn't seem to be Android related. It also appears on the desktop version, so it might be an error that is thrown from Gecko.
I did a small investigation and I'll be adding some screen records and some logs that might be helpful when investigating further.

Comment 3

[Alexandra Virvara]

Attachment: The response headers that are received after the download is resumed (for the case where the bug doesn't reproduce))

Comment 4

[Alexandra Virvara]

Attachment: The response headers that are received after the download is resumed (for the case where the bug happens)

Comment 5

[Alexandra Virvara]

Attachment: Desktop: the download works well after resuming it

Comment 6

[Alexandra Virvara]

Attachment: Mobile: the download doesn't work after resuming it

Comment 7

[Alexandra Virvara]

Attachment: Desktop: the download doesn't work after resuming it

Comment 8

[Alexandra Virvara]

Attachment: Mobile: the download works well after resuming it

Comment 9

[Iorga Gabriel]

I think the problem is we put the "Range" header value when the download is resumed, but the website doesn't respond with the "Content-Range" header value.
The response should be 206 from the resume, but the site response is 200, like we made the request from the beginning.
The same bug is on desktop. On Chrome or Brave I can't reproduce this bug.
Tried with HttpURLConnectionClient() instead of GeckoViewFetchClient still the same result.