830447 - Download of app for an install/update can get stuck during downloading of an app on a weak network connection

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Jason Smith [:jsmith]]

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

Steps:

1. Go to http://mozqa.com/webapi-permissions-tests/
2. Install "large appcache update" hosted app on a slow network connection

Expected:

A downloading notification should be seen.

Actual:

The homescreen app icon starts spinning, but no downloading notification is seen. I've waited at least five minutes so far haven't seen the app finish downloading. Here's what webapps.json says:

  "{a64cf49e-6cda-495c-903a-7262d64b865a}": {

    "name": "Large Appcache Update",

    "csp": "",

    "installOrigin": "http://mozqa.com",

    "origin": "http://mozqa.com",

    "receipts": [],

    "installTime": 1358192643850,

    "manifestURL": "http://mozqa.com/webapi-permissions-tests/large_appcache_update/manifest.webapp",

    "appStatus": 1,

    "removable": true,

    "id": "{a64cf49e-6cda-495c-903a-7262d64b865a}",

    "localId": 1023,

    "basePath": "/data/local/webapps",

    "progress": 0,

    "installState": "pending",

    "downloadAvailable": true,

    "downloading": true,

    "readyToApplyDownload": false,

    "downloadSize": 0,

    "lastUpdateCheck": 1358192643850,

    "etag": "\"401f-1ba-4d344a6a65c80\"",

    "installerAppId": 1016,

    "installerIsBrowser": true

  }

Comment 1

[Jason Smith [:jsmith]]

Btw - I can reproduce this relatively easily with Mozilla Guest in Mountain View.

Comment 2

[Jason Smith [:jsmith]]

So here's what I've discovered testing this:

On the 1st install of a hosted app preloading appcache with a weak network connection, we'll never finish installing.

Next, if I restart my phone, delete the app that failed to download, and try installing again - the app notification comes up late, but eventually downloading starts. Then, when the app finishes downloading (it actually does this time), the app homescreen icon still shows downloading for a period of time, even though the app is actually installed. Eventually we show the right icon.

I'm keeping this bug for the failure to install a hosted app preloading an appcache over a slow connection on the first try.

Other bugs will be filed for the other issues.

Comment 3

[Jason Smith [:jsmith]]

Note that this problem only reproduces with a *weak* network connection. A fast network connection will not reproduce this bug.

I still think this blocks though given that we're supposed to handle weak network connections.

I'm guessing given that we never finished downloading resources that this is a core gecko issue.

Comment 4

[Julien Wajsberg [:julienw]]

Let me explain some things here :
- the homescreen icon is added as soon as we get the 'oninstall' event, which means that the app was added in the internal DB.
- We display the notification when we get the first progress. We do this like this because this is the only way to know when we resume a download.
However, what me might do is displaying the notification at the "oninstall" event too. Then if there is a very long delay between oninstall and the first progress, we'd still have the event. Note that this couldn't be done for the resume install use case with the current mozApps API.

The same is done for update since Bug 826946 was fixed so I suspect you'd see the same problem.

Comment 5

[Julien Wajsberg [:julienw]]

Note also than on a very weak connection we should still get a downloaderror at one time, and be able to manually resume download.

Comment 6

[Jason Smith [:jsmith]]

Okay, so this gets more interesting now - this reproduces with a small packaged app as well.

Apparently we seem to have a lot trouble downloading an app that requires the download progress to go through on Mozilla Guest (weak network connnection).

Note that both apps are less than 20 KB in size.

Comment 7

[Jason Smith [:jsmith]]

Here's the webapps.json for the packaged app case:

  "{f14019ef-1564-46a7-a07d-af71a41c8229}": {

    "name": "Test WebAPI Permissions",

    "csp": "",

    "installOrigin": "http://mozqa.com",

    "origin": "app://{f14019ef-1564-46a7-a07d-af71a41c8229}",

    "receipts": [],

    "installTime": 1358197339202,

    "manifestURL": "http://mozqa.com/webapi-permissions-tests/webpackagedappwithperms.manifest",

    "appStatus": 1,

    "removable": true,

    "id": "{f14019ef-1564-46a7-a07d-af71a41c8229}",

    "localId": 1025,

    "basePath": "/data/local/webapps",

    "progress": 5233,

    "installState": "pending",

    "downloadAvailable": true,

    "downloading": true,

    "readyToApplyDownload": false,

    "downloadSize": 10000,

    "lastUpdateCheck": 1358197339202,

    "etag": "\"254069-16f-4d2c79ec6dbc0\"",

    "installerAppId": 1016,

    "installerIsBrowser": true

  }

Comment 8

[[:fabrice] Fabrice Desré]

Note that in this case, download has started (progress is 5233). If you wait long enough, do you get a network error and proper cleanup?

Comment 9

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #8)
> Note that in this case, download has started (progress is 5233). If you wait
> long enough, do you get a network error and proper cleanup?

On the first try I did not.

I'm going to reflash a fresh build, turn on nspr logging, and dump a log here to see anything jumps out on what seems odd.

Comment 10

[Jason Smith [:jsmith]]

Argh. Now the internet connection does not suck so I can't reproduce.

Comment 11

[Jason Smith [:jsmith]]

Going to have to remove nom for tef? until I can get more info. I'd still track this though.

Comment 12

[Jason Smith [:jsmith]]

Attachment: Logcat with NSPR Logging

Change that - I got another reproduction, except this time, doing an update instead.

Comment 13

[Julien Wajsberg [:julienw]]

Proposed concrete new bug that could block this one: show the download and update notifications as soon as possible (depending on the various cases).

Comment 14

[Jason Smith [:jsmith]]

The only idea I have that could be causing this failure is that we're making certain requests out and not knowing timeout eventually if there's not enough activity.

Comment 15

[Honza Bambas (:mayhemer)]

Could this be candidate for lame-network?

Comment 16

[Jason Smith [:jsmith]]

(In reply to Honza Bambas (:mayhemer) from comment #15)
> Could this be candidate for lame-network?

Hmm...querying on that whiteboard, this now almost feels like an "apps version" of bug 825598. The behavior and workflow is different with the 3rd party app downloading, but the problem we are attacking here feels similar.

Comment 17

[Jason Smith [:jsmith]]

So I'll try backing up and explaining the problem:

On a weak network connection, we can end getting stuck in the download process for an install or update. When I mean "stuck," I mean that the homescreen app icon starts spinning with no end in sight. Depending on the timing of this "stuck" phase, one of two things can happen:

If the "stuck" phase happens *before* the download notification begins, the only way you can kill the download process is to restart the phone and remove the app, as the user can only kill a download process for the download notification, not the homescreen icon.

If the "stuck" phase happens *after* the download notification begins, you can just kill the download by canceling the download of the app and uninstalling it.

This failure happens relatively easily on Mozilla Guest.

Comment 18

[Julien Wajsberg [:julienw]]

jason, do we actually get an error after a long time (ie 20 min for example) ?

Comment 19

[Jason Duell]

Assuming this is lame-network hanging the download, I think the fix here is to timeout the download at some point, and either just cancel and provide some UI to the user, or maybe try silently to re-download a few times, in case the network is good enough for long enough to successfully complete the download.   The latter would be great on wifi, but not if we're using the user's data plan.

Comment 20

[Alex Keybl [:akeybl]]

As long as after restart the app doesn't appear as if it's launchable (our understanding is that it's just a generic app icon) it should be obvious that the user needs to re-install the app that failed to install.

Comment 21

[Sylvestre Ledru [:Sylvestre]]

Core Graveyard / DOM: Apps is inactive. Closing all bugs in this component.