Closed
Bug 796820
Opened 12 years ago
Closed 12 years ago
Unable to launch an app whose manifest contains 'appcache_path'
Categories
(Firefox OS Graveyard :: Gaia, defect, P3)
Firefox OS Graveyard
Gaia
Tracking
(blocking-basecamp:+)
RESOLVED
DUPLICATE
of bug 802614
blocking-basecamp | + |
People
(Reporter: ghtobz, Assigned: ferjm)
Details
(Keywords: regression, Whiteboard: [label:homescreen])
Attachments
(4 files, 2 obsolete files)
[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?
Updated•12 years ago
|
Keywords: regression
Comment 1•12 years ago
|
||
Fabrice, do you know anything about this bug? Should it block the release?
blocking-basecamp: --- → ?
Comment 2•12 years ago
|
||
Talked in triage -> blocking. We should either not install, or support launching the app.
blocking-basecamp: ? → +
Updated•12 years ago
|
Summary: Cannot load an app whose manifest contains 'appcache_path' → Unable to launch an app whose manifest contains 'appcache_path'
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → ferjmoreno
Assignee | ||
Comment 3•12 years ago
|
||
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
Assignee | ||
Comment 4•12 years ago
|
||
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.
Assignee | ||
Comment 5•12 years ago
|
||
nsOfflineCacheUpdate debug output for appcache download error when installing http://people.mozilla.org/~cwiemeersch/mkt.html
Assignee | ||
Comment 6•12 years ago
|
||
Logcat output of the appcache download error when installing http://people.mozilla.org/~fdesre/openwebapps/test.html
Assignee | ||
Comment 7•12 years ago
|
||
nsOfflineCacheUpdate debug output for appcache download error when installing http://people.mozilla.org/~fdesre/openwebapps/test.html
Updated•12 years ago
|
Priority: -- → P3
Comment 8•12 years ago
|
||
This bug is blocking app review for Sonora, who is a tier 1 bizdev partner.
Comment 9•12 years ago
|
||
(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.
Assignee | ||
Comment 10•12 years ago
|
||
Done. Debug log adding "cache:5,nsHttp:5,timestamp".
Attachment #672811 -
Attachment is obsolete: true
Assignee | ||
Comment 11•12 years ago
|
||
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
Comment 12•12 years ago
|
||
(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•12 years ago
|
||
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•12 years ago
|
||
Question - Isn't this the root cause of this problem being fixed in bug 796045?
Comment 15•12 years ago
|
||
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•12 years ago
|
||
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.
Assignee | ||
Comment 17•12 years ago
|
||
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
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•