4.62 KB, text/plain
2.97 KB, text/plain
439.82 KB, text/plain
458.85 KB, text/plain
[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?
Fabrice, do you know anything about this bug? Should it block the release?
blocking-basecamp: --- → ?
Talked in triage -> blocking. We should either not install, or support launching the app.
blocking-basecamp: ? → +
Summary: Cannot load an app whose manifest contains 'appcache_path' → Unable to launch an app whose manifest contains 'appcache_path'
The appcache for the test application that cvan has mentioned in comment 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  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  is not handling the |mozIDOMApplication.ondownloaderror| . 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  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?  http://people.mozilla.org/~cwiemeersch/mkt.html  http://people.mozilla.org/~fdesre/openwebapps/test.html  https://github.com/mozilla-b2g/gaia/blob/master/apps/homescreen/js/appmanager.js#L91  http://mxr.mozilla.org/mozilla-central/source/dom/interfaces/apps/nsIDOMApplicationRegistry.idl#61  https://www.dropbox.com/sh/b0kyykhzcfkpm8b/fdA0gFkf5U/Gaia_AppInstall_20121011.pdf
Created attachment 672809 [details] 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.
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
Created attachment 672812 [details] Webapps appcache download success logcat Logcat output of the appcache download error when installing http://people.mozilla.org/~fdesre/openwebapps/test.html
Created attachment 672813 [details] nsOfflineCacheUpdate debug output for appcache download success nsOfflineCacheUpdate debug output for appcache download error when installing http://people.mozilla.org/~fdesre/openwebapps/test.html
This bug is blocking app review for Sonora, who is a tier 1 bizdev partner.
(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.
Created attachment 676744 [details] nsOfflineCacheUpdate debug output for appcache download error Done. Debug log adding "cache:5,nsHttp:5,timestamp".
Attachment #672811 - Attachment is obsolete: true
Created attachment 676747 [details] 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! :)
Attachment #672813 - Attachment is obsolete: true
(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
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.
Question - Isn't this the root cause of this problem being fixed in bug 796045?
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.
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.
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.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 802614
You need to log in before you can comment on or make changes to this bug.