When an 3rd party app update is presented, it fails to download successfully and does not remove the app from the notification window. So the user will keep trying in a loop. See screencast: http://youtu.be/xj3gcgyTCWw Logcat: 12-19 10:57:49.197: E/GeckoConsole(110): Content JS INFO at app://system.gaiamobile.org/js/updatable.js:89 in anonymous: downloadError event, error code is APP_CACHE_DOWNLOAD_ERROR 12-19 10:57:49.197: E/GeckoConsole(110): Content JS INFO at app://system.gaiamobile.org/js/app_install_manager.js:191 in ai_handleDownloadError: downloadError event, error code is APP_CACHE_DOWNLOAD_ERROR Repro: 1) install 20121218070200 unagi nightly build 2) install 3rd party app from marketplace (eg. Dictionary) 3) wait for app update to detect there's an update. pull down notification window and apply the update 4) verify download fails, and the update notification is not dismissed. Expected: - download successful Actual: - download fails, and the notification remains there. users will get stuck trying to update if it fails.

APP_CACHE_DOWNLOAD_ERROR means that the appcache is somewhat wrong, and we rightly fire a download error. Redirecting to gaia people since this may be on their side.

We actually catch this correctly as the log comes from our code. I think everything actually happens as expected : * an update is available => we display the update available notification * the user wants to download and apply this update => we remove the update available notification, and we display the downloading notification * this fails => we remove the downloading notification * an update is still available => we display the update available notification And that's it. Asking for an advice from our UX masters.

What could be the gaia workaround to not provide update message again ?

Guys, we gotta find a workaround to remove the update available message. currently, the download fails (because of busted the busted appcache manifest), but the user continues to see the "update is available". so they'll keep tapping it thinking they did something wrong; only they'll never get the download to work. The blocker is, the user could be on a data plan, and each time we send update pings to the server, we are consuming small amounts of carrier data. Thats not acceptable, if they are going to be stuck with a busted manifest that the app itself can't fix. See screenshot. the ping in this example consumed 3.11kb of real data. imagine tapping this 10 times, and the user already ate ~30kb of data without seeing a solution in site.

We could keep the manifest etag/last-modified headers in the platform, and not sending the downloadavailable event if we already did. This would still not work if the server doesn't send one of these headers but the marketplace does send ETag and I think most servers (at least Apache) send these by default if the file is static (and I suspect manifest will be). Fabrice, any thought about this ?

The appcache download can fail for many reasons, not just because the manifest itself is incorrect, but eg if one resource can't be downloaded. There's no way to track this on the webapps side because that happens deep inside the appcache code.

Honza - Any thoughts on the above discussion? We've apparently hit an app that preloads the appcache that is continuously failing to download on an update.

Hmm... I don't see a v1 fix for this. The good news is, the user doesn't have to get stuck in the loop. They can either ignore the update notification, or open it and deselect the problematic app from the list of available updates. It's a clunky work around, but it will work. _If_ we knew why the update failed, we could implement a more granular approach, but per Fabrice, it doesn't sound like that's possible in v1.

I'd say that this would be caught first by the developer (because he's the first to try his app) and so we might think that the end-user won't encounter this so often.

Hmm...sounds like this is not a blocker then, but dev-docs may be useful here.

(In reply to Jason Smith [:jsmith] from comment #7) > Honza - Any thoughts on the above discussion? We've apparently hit an app > that preloads the appcache that is continuously failing to download on an > update. This is more a UX problem, IMO. We should stop displaying an update-avail notification for the manifest path until user checks *manually* for updates or until a device restart or say 24 hours has passed. This can be done in the UI code. I presume the notification is based on checkForUpdate API? To make the 24hours case simpler, we might add some code (a failure-list) to offline cache update service to return FALSE for previously failed manifests. Only after the manifest has changed again, we will return TRUE. However, when the download error is just because of a missing file, we will still return FALSE after the missing file has been published and the update would actually work (if we ever try). This failure-list check must bypass when a manual update is triggered.

I dug into this a bit more. Looks like we can't complete a download of any hosted app that preloads the appcache right now. I'll leave this open for the UX issue and open a new bug for underlying cause of the problem that's happening right now. See bug 824203 for the actual problem here.

im still concerned that each time a user clicks that notification, it's sending real data pings on a data plan. can we get ux input on how we can dismiss the notification dialog if it's in this busted appcache state?

(In reply to Tony Chung [:tchung] from comment #13) > im still concerned that each time a user clicks that notification, it's > sending real data pings on a data plan. can we get ux input on how we can > dismiss the notification dialog if it's in this busted appcache state? The issue you were seeing was another bug about the fact that we have apps on marketplace that have invalid mime types for their appcache manifest, so if you try to update those apps, you will always fail. About the notification issue - see bug 825814. At this time, we can never get rid of an update notification at all unless you uninstall the app and restart the phone. I'm going to renom on that basis then.

I have this issue with my app but it has the correct AppCache Content-type AFAICT and I don't see AppCache errors reported on desktop Firefox or on Chrome. App name in Marketplace: Slithering Origin: http://snake-app.github.com/ AppCache Manifest: http://snake-app.github.com/snake.appcache

To be clear, I do see the same two errors as comment 0 on unagi.

(In reply to Matthew N. [:MattN] from comment #15) > I have this issue with my app but it has the correct AppCache Content-type > AFAICT and I don't see AppCache errors reported on desktop Firefox or on > Chrome. > > App name in Marketplace: Slithering > Origin: http://snake-app.github.com/ > AppCache Manifest: http://snake-app.github.com/snake.appcache Hmm...okay. Let me take a look at this when I wake up in 5 hours.

(In reply to Matthew N. [:MattN] from comment #16) > To be clear, I do see the same two errors as comment 0 on unagi. And the classic Error Console's Messages says?

(In reply to Honza Bambas (:mayhemer) from comment #18) > (In reply to Matthew N. [:MattN] from comment #16) > > To be clear, I do see the same two errors as comment 0 on unagi. > > And the classic Error Console's Messages says? Like I said in comment 15, there are no errors, only: Offline cache doesn't need to update, URL=http://snake-app.github.com/snake.appcache

Matthew N., can you please open a new bug for your particular issue? It seems different from what we are trying to solve here, though it may have similar symptoms. Please also provide detailed info on what exactly you expect and what is actually happening. Thanks.

(In reply to Honza Bambas (:mayhemer) from comment #20) > Matthew N., can you please open a new bug for your particular issue? It > seems different from what we are trying to solve here, though it may have > similar symptoms. Please also provide detailed info on what exactly you > expect and what is actually happening. Thanks. Bug 829853 filed.

Removing qawanted as I think Julien figured out the problem in the related bug.

So let's get back to this bug which is about not showing an update if it just failed, unless the user specifically forces checking for updates.

I'm closing this as this is being fixed in different bugs we're tracking. No need to continue tracking this specific case.