Closed Bug 833708 Opened 9 years ago Closed 9 years ago

[OTA] No error shown when no space left on device to download the update


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

Gonk (Firefox OS)
Not set


(blocking-b2g:tef+, b2g18+ verified, b2g18-v1.0.0 wontfix, b2g18-v1.0.1 verified)

B2G C4 (2jan on)
blocking-b2g tef+
Tracking Status
b2g18 + verified
b2g18-v1.0.0 --- wontfix
b2g18-v1.0.1 --- verified


(Reporter: rafael.marquez, Assigned: marshall)




(2 files, 1 obsolete file)

1-Try to fill the system memory until only 20MB are left
2-Tap to download a new update when it´s available

Expected result --> Receive some kind of error message stating that no space left on device

Actual result --> Update download "starts" as usual. You can see the following message in the |adb logcat|

I/Gecko   (   96): DirectoryProvider: Error: No volume found with 109293980 bytes for downloading update Firefox 18.0a2
I/Gecko   (   96): UpdatePrompt: Error downloading update Firefox 18.0a2: 0
I/Gecko   (   96): UpdatePrompt: Update error, state: null, errorCode: 0
I/Gecko   (   96): UpdatePrompt: Setting gecko.updateStatus: null
I/GeckoDump(   96): XXX FIXME : Got a mozContentEvent: update-available-result
blocking-b2g: --- → tef?
tracking-b2g18: --- → ?
This might be a dupe. There's a general bug I think on the fact that we don't do a good job reporting errors when an update fails. The error fails to show up at the right time, and instead randomly shows up in later usage. Something like "There was an error downloading your updates."
Whiteboard: DUPEME
CCing Dave as well, we recently talked about error handling, he might have a good idea.
Normally, when we get an error while downloading (the "update-error" mozChromeEvent), we should have a SystemBanner message appearing. Maybe the reporter didn't see it because it disappear after a few seconds.

At least the phone is still usable and not left in an unusable state. But it won't have system updates any more and the user doesn't know this if he missed the banner. The banner isn't even specific to system updates, the same banner is displayed for app updates.
Assignee: nobody → dhylands
blocking-b2g: tef? → -
Assignee: dhylands → marshall
Attached patch gecko errorCode fix + test - v1 (obsolete) — Splinter Review
first stab at fixing the behavior of the swallowed FILE_TOO_BIG error by setting
the active update's errorCode directly. the new test verifies the behavior, but
I also need to verify this for gaia.
Attachment #716264 - Flags: review?(dhylands)
Comment on attachment 716264 [details] [diff] [review]
gecko errorCode fix + test - v1

Review of attachment 716264 [details] [diff] [review]:

::: b2g/components/DirectoryProvider.js
@@ +103,5 @@
>    },
>    findUpdateDirWithFreeSpace: function dp_findUpdateDirWithFreeSpace(requiredSpace, subdir) {
>      if (!Services.volumeService) {
> +      log("Warning: Volume service is not running");

This would be normal on B2G-desktop

::: b2g/components/UpdatePrompt.js
@@ +314,5 @@
>      }
>      log("Error downloading update " + + ": " + aUpdate.errorCode);
> +    let errorCode = aUpdate.errorCode >>> 0;
> +    if (errorCode == FILE_ERROR_TOO_BIG) {

Shouldn't this be Cr.NS_ERROR_FILE_TOO_BIG ?

::: toolkit/mozapps/update/test/unit/xpcshell.ini
@@ +31,5 @@
>  [test_bug595059.js]
>  skip-if = toolkit == "gonk"
>  reason = custom nsIUpdatePrompt
>  [test_bug794211.js]
> +[test_bug833708.js]

This should be a gonk-only test right?
Blocks: 838247
the 'update-error' event is being sent back to gaia on the same stack as gaia's
call to 'update-download-result', which makes the gaia call to 
removeFromDownloadsQueue() happen before addToDownloadsQueue(). updated unit
tests to reflect this.
Attachment #717270 - Flags: review?(etienne)
this has been tested and confirmed working with gaia now (see new gaia patch)
Attachment #716264 - Attachment is obsolete: true
Attachment #716264 - Flags: review?(dhylands)
Attachment #717273 - Flags: review?(dhylands)
Re-nominating, blocks bug 838247, which is a blocker.
blocking-b2g: - → tef?
Attachment #717273 - Flags: review?(dhylands) → review+
Attachment #717270 - Flags: review?(etienne) → review+
blocking-b2g: tef? → tef+
Giving this a try run because of the new xpcshell test:
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: DUPEME
Target Milestone: --- → B2G C4 (2jan on)
Did the Gaia portion of this patch land on master?
Flags: needinfo?(marshall)
Uplifting commit ec6d010f907a69059853b20c36a5117cf890e8d5:
v1-train: 8e55fe64809d73b9dbd78344c4324cee366530c7
v1.0.1: fac1a3ad598e49081d3273c271021290f2574390
Adding flag moztrap+ because there is an adequate test case in MozTrap for this bug.
Flags: in-moztrap+
Verified fixed on 
Unagi Build ID: 20130403070201
Kernel Date: Dec 5
Gaia: daea430624ec02f8d36a12d581fc4a3278c27cb7


Unagi Build ID: 20130403070204
Kernel Date: Dec 5
Gaia: 06e0e5ce42bdfb62bdbe38271de6b5b2d9e40e75

Error shown when no space left on device to download the update. Does not Repro.
You need to log in before you can comment on or make changes to this bug.