1547648 - Download stuck in library, Can't be removed

Status: NEW

(Firefox :: Downloads Panel, defect, P5)

Description

[Ran Sagy]

Attachment: ffbug[1].png

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:66.0) Gecko/20100101 Firefox/66.0

Steps to reproduce:

Start a download for a file.

Actual results:

File is stuck indefinitely in the Downloads view of the Library with "Unknown time left - 0 bytes (0 bytes/sec)" and cannot be canceled or removed, Either from the preview panel in the main UI or the one in the library.

Expected results:

Download should have succeeded, failed or it should have been possible to stop/remove it.

Comment 1

[Marco Bonardo [:mak]]

Does this status persist after restarting Firefox, or is it just for the current session?
It sounds like we missed some notification from the network stack.
If it happens again, could you please check in the Browser Console if there's any errors reported?

Comment 2

[Ran Sagy]

It persisted initially. After a few days (where that machine was even turned off) it went away.
I'll keep it in mind if it happens again, Thanks.

Comment 3

[Marco Bonardo [:mak]]

it's possible on restart we tried to restart the download, thinking it was still ongoing. It may depend on some specific server-side quirks, that makes this hard to reproduce. Thus setting as a P%, hopefully it happens again and you find some useful error report in the console :/

Comment 4

[Berend De Schouwer]

I've seen this today on FF 83 on Linux.

The only more information I can give you is that my network briefly paused, resulting in a valid connection (no disconnect) but no packets sent or received.

Some downloads in FF did stop: downloads where the file size was known. The download that is un-cancellable have an "unknown size, unknown time".

The unknown size downloads did not yet open a file. No 0-byte file, no .part file, nothing. Before restart, so any dangling file handles should still be around.

I assume the download was queued but not started because the HTTPS connection hasn't yet received a header or incomplete header. HTTPS, not HTTP, so it may be incomplete TLS negotiation.

I am not the original reporter, so this is a confirmation that it can indeed happen, but not often.

This is on Linux, the original was on Windows, which historically means subtle network stack differences.

Comment 5

[Ran Sagy]

While i haven't encountered this since, It was on the work computer that is on a VPN most of the time, so it might very well have been related to a (silently-)dropped network connection indeed.