796820 - Unable to launch an app whose manifest contains 'appcache_path'

Status: RESOLVED DUPLICATE of bug 802614

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

Description

[GH to BZ]

[GitHub issue by cvan on 2012-10-01T22:29:19Z, https://github.com/mozilla-b2g/gaia/issues/5604]
Load http://bit.ly/QmZVTg or call

    navigator.mozApps.install('https://marketplace-dev.allizom.org/manifest.webapp')

installation works okay, but now try clicking on the app on the homescreen to launch. Nothing happens. And no activity in `adb logcat`.

According to W3C's validator, the [appcache manifest is valid](http://manifest-validator.com/api/validate?uri=https://marketplace-dev.allizom.org/appcache/manifest.appcache).

If I load http://bit.ly/SUO5Sm or call

    navigator.mozApps.install('https://marketplace-dev.allizom.org/manifest.webapp?skip_appcache')

installation and loading works fine.

Any ideas here?

Comment 1

[Dietrich Ayala (:dietrich)]

Fabrice, do you know anything about this bug? Should it block the release?

Comment 2

[Dietrich Ayala (:dietrich)]

Talked in triage -> blocking. We should either not install, or support launching the app.

Comment 3

[Fernando Jiménez Moreno [:ferjm]]

The appcache for the test application that cvan has mentioned in comment 1 [1] is not being properly downloaded. I couldn't find the reason so far. I have to do a deeper debugging in the |nsOfflineCacheUpdate| component to see why it is failing. It might just be because of the appcache itself and not a platform issue.

Anyway, the test application provided by Fabrice [2] is properly being installed and can be launched as expected, so installing an app whose manifest contains 'appcache_path' doesn't seem to be the issue here.

The actual problem that I can see here is that the Gaia side is not properly handling the case where the appcache download fails. I've noticed that the Gaia appmanager.js [3] is not handling the |mozIDOMApplication.ondownloaderror| [4]. In fact, is not tracking the app download at all. I've added a mock handler to it and I've checked that the |mozIDOMApplication.ondownloaderror| is properly being sent by the platform, but that lead me to a different issue which is that this event is triggered a *lot* of times. Fortunately this issue is gonna be fixed once Bug 795164 lands.

I've seen that the app installation error handling is required as part of the new app install spec [5] and is being tracked in Bug 802574 (specifically Bug 802614 and Bug 802615), so I am tempted to close this bug as WONTFIX. Is that ok for you?

[1] http://people.mozilla.org/~cwiemeersch/mkt.html
[2] http://people.mozilla.org/~fdesre/openwebapps/test.html
[3] https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/js/appmanager.js#L91
[4] http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/apps/nsIDOMApplicationRegistry.idl#61
[5] https://www.dropbox.com/sh/b0kyykhzcfkpm8b/fdA0gFkf5U/Gaia_AppInstall_20121011.pdf

Comment 4

[Fernando Jiménez Moreno [:ferjm]]

Attachment: Webapps appcache download error logcat

I've taken a few logs, just in case that you want to check it.

This one contains the logcat output of the appcache download error when installing http://people.mozilla.org/~cwiemeersch/mkt.html with Webapps debug activated.

Comment 5

[Fernando Jiménez Moreno [:ferjm]]

Attachment: nsOfflineCacheUpdate debug output for appcache download error

nsOfflineCacheUpdate debug output for appcache download error when installing http://people.mozilla.org/~cwiemeersch/mkt.html

Comment 6

[Fernando Jiménez Moreno [:ferjm]]

Attachment: Webapps appcache download success logcat

Logcat output of the appcache download error when installing http://people.mozilla.org/~fdesre/openwebapps/test.html

Comment 7

[Fernando Jiménez Moreno [:ferjm]]

Attachment: nsOfflineCacheUpdate debug output for appcache download success

nsOfflineCacheUpdate debug output for appcache download error when installing http://people.mozilla.org/~fdesre/openwebapps/test.html

Comment 8

[Lisa Brewster [:adora]]

This bug is blocking app review for Sonora, who is a tier 1 bizdev partner.

Comment 9

[Honza Bambas (:mayhemer)]

(In reply to Fernando Jiménez Moreno [:ferjm] from comment #5)
> Created attachment 672811 [details]
> nsOfflineCacheUpdate debug output for appcache download error
> 
> nsOfflineCacheUpdate debug output for appcache download error when
> installing http://people.mozilla.org/~cwiemeersch/mkt.html

Could you please also include "cache:5,nsHttp:5,timestamp" to your module list?  Thanks.

Comment 10

[Fernando Jiménez Moreno [:ferjm]]

Attachment: nsOfflineCacheUpdate debug output for appcache download error

Done. Debug log adding "cache:5,nsHttp:5,timestamp".

Comment 11

[Fernando Jiménez Moreno [:ferjm]]

Attachment: nsOfflineCacheUpdate debug output for appcache download success

Not sure if you also need it, but here it goes the log for a successful download adding "cache:5,nsHttp:5,timestamp".

Thanks a lot for your help! :)

Comment 12

[Honza Bambas (:mayhemer)]

(In reply to Fernando Jiménez Moreno [:ferjm] (PTO until 5th Nov) from comment #10)
> Created attachment 676744 [details]
> nsOfflineCacheUpdate debug output for appcache download error
> 
> Done. Debug log adding "cache:5,nsHttp:5,timestamp".

I can see that channel for https://marketplace-dev.allizom.org/media/img/mkt/grain.png is being canceled with NS_ERROR_ABORT (cancel is called on the channel) in some redirect callback.

2012-10-30 20:13:24.165092 UTC - 2050918752[101f61660]: nsHttpChannel::Cancel [this=1166eb800 status=80004004]
2012-10-30 20:13:24.165109 UTC - 2050918752[101f61660]: channel canceled during wait for redirect callback

Comment 13

[Honza Bambas (:mayhemer)]

Change it on the manifest to https://marketplace-dev-cdn.allizom.org/media/img/mkt/grain.png and you are OK.

It is by the spec to fail the load when some resource leads to a redirect.

Comment 14

[Jason Smith [:jsmith]]

Question - Isn't this the root cause of this problem being fixed in bug 796045?

Comment 15

[Alexandre Poirot [:ochameau]]

No, it fixed something else. It make it work again but doesn't solve the particular issue being described here and refined in comment 3.

The error isn't about having an appcache_path attribute. We are having some unexpected behavior when the appacache manifest has an error. Like:
- refers to a file that doesn't exists,
- refer to a file which is redirected,
- .. so on.

As Honza just said, per spec definition, various such "error" while downloading files described by the manifest file ends up throwing an error from the appcache component. So that webapps code doesn't succeed installing the webapp as this appcache component says it is failing.
The main issue here is that the error doesn't bubbles up to Gaia homescreen/system apps and the user doesn't receive any message about such error. We just end up with an app icon on homescreen that does nothing.
Actually, I discussed with etienne_s and a message might come up some minutes after installation, from code handling system/app updates. And I thing I've seen this message once while reproducing this bug.

Comment 16

[Honza Bambas (:mayhemer)]

We definitely fire applicationCache.onerror in the content.  But when using API from bug 796045 there is no applicationCache content object.  There are though other ways to observe update status, since you have it in hands and can add observers to it (see nsIOfflineCacheUpdate interface).  This is just for info, not sure whether this is already being solved in some other bug.

Comment 17

[Fernando Jiménez Moreno [:ferjm]]

Thanks a lot for your help Honza! This clarifies the issue.

(In reply to Alexandre Poirot (:ochameau) from comment #15)
> The main issue here is that the error doesn't bubbles up to Gaia
> homescreen/system apps and the user doesn't receive any message about such
> error. We just end up with an app icon on homescreen that does nothing.

As I explained in comment 3, the error (APP_CACHE_DOWNLOAD_ERROR via 'ondownloaderror') is being fired by the WebApps implementation but it is not being properly handled in Gaia. So I am closing this as dup of Bug 802614, which is tracking the work needed to notify the user about a failed installation because of a download failure caused by a network error. Please, reopen it if you consider that there is any other work to be done here.