Closed Bug 828267 Opened 11 years ago Closed 11 years ago

Installing a packaged app, lose connection during download, remove it, install it again - network error doesn't fire and app infinitely spins trying to download resources

Categories

(Core Graveyard :: DOM: Apps, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-basecamp:-, firefox19 wontfix, firefox20 wontfix, firefox21 fixed, b2g18+ fixed)

VERIFIED FIXED
mozilla21
blocking-basecamp -
Tracking Status
firefox19 --- wontfix
firefox20 --- wontfix
firefox21 --- fixed
b2g18 + fixed

People

(Reporter: jsmith, Assigned: fabrice)

References

Details

Attachments

(1 file)

Build: B2G 18 1/9/2013
Device: Unagi

Steps:

1. Start a download of a packaged app that's large (http://mozqa.com/webapi-permissions-tests/ Packaged App Test Case 5)
2. Kill the network connection
3. Remove that app from the homescreen
4. Try installing that app again

Expected:

A network error should immediately be thrown - we don't have a network connection to install the app.

Actual:

We start downloading the app resources even though we don't have a network connection. The app starts spinning forever in a downloading state. No error is fired to the user.

Error Console:

01-09 14:08:22.379: E/GeckoConsole(109): [JavaScript Error: "[Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIHttpChannel.responseStatus]"  nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)"  location: "JS frame :: resource://gre/modules/Webapps.jsm :: <TOP_LEVEL> :: line 1854"  data: no]" {file: "resource://gre/modules/Webapps.jsm" line: 1854}]

My hunch is that we're blowing up on the etag check.
blocking-basecamp: --- → ?
Another STR that reproduces this behavior:

1. Install a packaged app
2. Kill the network connection
3. Try restarting the download without a network connection
We fail at https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1879
I think that just moving the block at https://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#1900 before the responseStatus block will fix that. Patch coming asap.
Attached patch patchSplinter Review
Jason verified on a build with this patch that this is fixing the issue.
Assignee: nobody → fabrice
Attachment #699825 - Flags: review?(jst)
Comment on attachment 699825 [details] [diff] [review]
patch

JST says r=JST
Attachment #699825 - Flags: review?(jst) → review+
blocking-basecamp: ? → -
tracking-b2g18: --- → +
Comment on attachment 699825 [details] [diff] [review]
patch

[Approval Request Comment]
Bug caused by (feature/regressing bug #): 
User impact if declined: network errors are not reported properly during package download, leading to a confusing UI.
Testing completed: yes
Risk to taking this patch (and alternatives if risky): no risk
String or UUID changes made by this patch: none
Attachment #699825 - Flags: approval-mozilla-b2g18+
https://hg.mozilla.org/mozilla-central/rev/4eb969119718
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla21
Verified when I tested Fabrice's patch directly.

Ed - Can you land this on b2g18?
Flags: needinfo?(emorley)
Status: RESOLVED → VERIFIED
Flags: needinfo?(emorley)
https://hg.mozilla.org/releases/mozilla-b2g18/rev/c0b05b8ea81c
Status: VERIFIED → RESOLVED
Closed: 11 years ago11 years ago
Status: RESOLVED → VERIFIED
Blocks: app-install
No longer blocks: market-packaged-apps
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.