957985 - [Download Manager] Failed downloads are not displayed successfully in download list

Status: VERIFIED FIXED

(Firefox OS Graveyard :: Gaia::Settings, defect)

Description

[rafael.marquez]

Attachment: failed.jpg

*Procedure
1. Download a  file
2. Turn off internet connection during the download proccess
3. the download is displayed as failed


*Expected Result
The failed download is displayed successfully (see the attached file)

*Actual Result
The failed download is not displayed successfully. The text failed is not displayed and the progress bar is not removed

Comment 1

[Cristian Rodriguez (:crdlc)]

Gecko: c60683e

I think there is a problem when we try to access to the error attribute of the download object. Maybe it appeared during 2-3 latest weeks because before my xmas holidays it was working fine. Do you know what could be happening Ghislain?

[JavaScript Error: "Return value of DOMDownload.error is not an object."]

Comment 2

[rafael.marquez]

In the current version the bug has changed. The failed download is not displayed successfully. The text "stopped" is displayed but should display the text "failed"

Comment 3

[Cristian Rodriguez (:crdlc)]

Gecko: 12dd20e
Gaia-e771f17

Installing the latest build today the problem is that the download.error is null when the device loose the wifi signal although the state is stopped (this is ok). The issue is the error attribute thought. It should be different than null in this scenario. Ghislain forget my comment 1 and focus on this one.

Thanks a lot

Comment 4

[Aus Lacroix [:aus]]

What happens when connection is regained? Does the download resume or, is it resumable?

Comment 5

[Cristian Rodriguez (:crdlc)]

The download is resumed automatically if the device is online again although I will double check it

Comment 6

[Cristian Rodriguez (:crdlc)]

Resumable downloads:

  They are resumed automatically when the device gets online. If the device loses the connection, the downloads appear like stopped (download.error === null) and when the connection is regained they are resumed automatically and it works fine.

Non resumable downloads:

  If the device loses the connection, the downloads appear like stopped (download.error === null) and when the connection is regained, the device tries to resume them unsuccessfully and they appear as failed immediately.

The first case makes sense although the second one seems weird for me. 

Please, UX and API input?

Thanks a lot

Comment 7

[Aus Lacroix [:aus]]

Cristian, I'll chat with Francis about it and see what he thinks. I'm not sure that we have many options at this time. 

It's difficult to determine whether a server will be able to resume a download or not. Some servers, for efficiency, will return an HTTP 1.0 response when clients do not send a Range header. So, detecting http 1.0 vs 1.1 wouldn't necessarily help us for all cases.

We'll respond here after we chat. :)

Comment 8

[Francis Djabri [:djabber]]

Christian, I spoke with Aus - if we can't reliably detect if a download is non-resumable in advance, then I think the current behaviour would be ok. If we could detect that the download is non-resumable, then we should fail the download when losing connectivity, rather than putting it in the intermediate stopped state.

Comment 9

[Francis Djabri [:djabber]]

Just to clarify - given that we can't reliably detect if the download is resumable in advance, let's stick with the current behaviour. :)

Comment 10

[Cristian Rodriguez (:crdlc)]

Thanks to clarify this

Rafa, 

   Could you check what current implementation works in that way? (see comment 8 and comment 9) If it works fine we will close it, right?

* Resumable downloads:

  They are resumed automatically when the device gets online. If the device loses the connection, the downloads appear like stopped and when the connection is regained they are resumed automatically and it works fine.

* Non resumable downloads:

  If the device loses the connection, the downloads appear like stopped and when the connection is regained, the device tries to resume them unsuccessfully and they appear as failed immediately.

Comment 11

[Cristian Rodriguez (:crdlc)]

Upps, I forgot the needinfo tag

Comment 12

[rafael.marquez]

Attachment: IntentoFallido.png

Comment 13

[rafael.marquez]

* Resumable downloads: Works fine

* Non resumable downloads: Has a visual problem
When the connection is regained, the device tries to resume them unsuccessfully and they appear as failed immediately but progress  bar doesn't disappears. See the screenshot attached.

Comment 14

[Cristian Rodriguez (:crdlc)]

OK, I understand. We have a visual issue in download list. OK thanks for your help!

Comment 15

[Cristian Rodriguez (:crdlc)]

Attachment: Patch v1

Thanks guys for the review

Comment 16

[Borja Salguero [:borjasalguero]]

Rafa, could you check this with master? I've just landed a patch which is adding https://github.com/mozilla-b2g/gaia/blob/master/apps/settings/style/downloads.css#L223, so probably it's fixed now!

Comment 17

[Cristian Rodriguez (:crdlc)]

This bug was fixed for this commit (bug 957584):

https://github.com/mozilla-b2g/gaia/commit/96d2fb464261463f9cbc56dd5fcbc77c52a67e99