Closed Bug 981539 Opened 6 years ago Closed 6 years ago

[Download Manager] A strange message is displayed when the SD is completely full


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

Not set


(blocking-b2g:1.4+, firefox29 wontfix, firefox30 fixed, firefox31 fixed, b2g-v1.4 fixed, b2g-v2.0 fixed)

1.4 S5 (11apr)
blocking-b2g 1.4+
Tracking Status
firefox29 --- wontfix
firefox30 --- fixed
firefox31 --- fixed
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed


(Reporter: rafael.marquez, Assigned: aus)



(Whiteboard: [systemsfe][p=3])


(5 files, 1 obsolete file)

Attached image correct.JPG
Having a SD card inserted which is full with 1 Mb free

1. Open browser app
2. Open a webpage whitch  you can download files.
3. Download a file which has a size bigger than the empty space in the sd card.

  A correct error message is displayed "correct.JPG" (attached image)

4. Open a webpage whitch  you can download files.
5. Download a file which has a size bigger than the empty space in the sd card.

*Actual Result
 Two no correct messages are displayed  "no correct 1.JPG" and  "no correct 2.JPG" (attached images)

*Expected Result
The message shown in the screenshot "correct.JPG" is displayed in both cases
Attached image no correct 1.JPG
Attached image no correct 2.JPG
Francis, Can you verify if my opinion is correct?
Flags: needinfo?(fdjabri)
Whiteboard: [systemsfe]
blocking-b2g: --- → 1.4?
Hi Rafael, yes that's correct and according to the spec. Thanks for picking up on this.
Flags: needinfo?(fdjabri)

   According to comment 4, the UI that we should show is this one as Gaia does. Furthermore, there are two consecutive error messages.

Thanks a lot
Flags: needinfo?(aus)
blocking-b2g: 1.4? → 1.4+
Currently we do not do any space check before starting a download. Furthermore, it's not always possible for us to do so. Do we not get an error attached to the download object with a state change when the SD card becomes full during download?
Flags: needinfo?(aus)
Yes, this error is displayed when we receive an 'stopped' state with error !== null
OK, good! :) We should be able to add additional checks when we see the error in the Downloads API itself and provide a better error message. Or we could try and get the underlying necko bits that fail to write to disk to provide a better error. We'll see which one makes more sense once I dig into this a little bit more.
Assignee: nobody → aus
Target Milestone: --- → 1.4 S4 (28mar)
any update to this bug?
Unfortunately no, this is likely to only get my attention next week as other issues have become more complex than expected.
OK, this should be easier to fix if we go for the more elaborate solution in bug 982006, if we don't, it will be a minor patch to the External Helper App Service once again to provide the original leaf name of the file when available instead of the temporary filename (and full path! ugh!) of the download.
Depends on: 982006
Target Milestone: 1.4 S4 (28mar) → 1.4 S5 (11apr)
I'm hoping now that 982006 has landed that we'll be able to resolve this quickly.
Whiteboard: [systemsfe] → [systemsfe][p=3]
OK, unfortunately, this will require handling the write errors that occur when running out of space differently than how gecko currently handles them. I should have something tomorrow that fixes the issue (and gets rid of the extra alert).
Comment on attachment 8401623 [details] [diff] [review]
Patch - v1 - Ensure mTransfer instance in case of failure when OnSaveComplete is called.

Attachment #8401623 - Flags: review?(bzbarsky) → review+
Comment on attachment 8401627 [details] [review]
Pull Request - Handle new error returned for no disk space.

Good job, thanks
Attachment #8401627 - Flags: review?(crdlc) → review+
* Fixed compile error in release mode by removing unused variable.
Attachment #8401623 - Attachment is obsolete: true
Attachment #8401906 - Flags: review+
Keywords: checkin-needed
Closed: 6 years ago
Resolution: --- → FIXED
Verified in v1.4 and v1.5
You need to log in before you can comment on or make changes to this bug.