Currently, when I tap the 'Firefox Marketplace' icon in the apps dashboard, nothing happens. Steps to reproduce (With a new profile) i) Launch Nightly, visit the Apps dashboard ii) Install the Firefox Marketplace by opting in through the doorhanger-prompt iii) Swap back to Nightly, visit the Apps dashboard and the Firefox Marketplace shortcut icon ER: Swap back to Firefox Marketplace AR: Nothing on tap Nothing produced in console. Thinking this is a recent regression. -- Samsung Galaxy Nexus (Android 4.1.1) Asus Nexus 7 (Android 4.1.1) Nightly (10/02)
Even on new cold-start (fennec relaunching after quit), the shortcut in the apps dashboard is a dud.
This seems to be a problem with some changes in dom/apps/WebApps.jsm. We're failing at: http://mxr.mozilla.org/mozilla-central/source/dom/apps/src/Webapps.jsm#581 We currently just race on and don't wait for the appcache to download, so I suspect this might be our problem. Launching from about:apps would typically happen long after the app is installed though. Not sure though? Fabrice?
This is likely a regression from the install/update API landing.
(In reply to Jason Smith [:jsmith] from comment #4) > This is likely a regression from the install/update API landing. Tracking bug for reference - https://bugzilla.mozilla.org/show_bug.cgi?id=790558. Any resolved fixed bug under that bug in the depends list could have caused this regression.
I think we're failing to parse the manifest. I don't know enough about these to know if its a problem with the manifest or a bug in us: https://marketplace.mozilla.org/appcache/manifest.appcache
Created attachment 667658 [details] [diff] [review] patch Wes, can you test with this patch? That does not fix the situation where the appcache has errors, we need to check with Jonas what we want to do there.
I think that if the appcache has errors, we should *not* transparently let the user run the app from the website. Putting an appcache link in the webapp manifest basically means "run this app using appcache". If we're unable to download the appcache but still allow the user to transparently still run the app then we're essentially breaking that contract. This has a pretty big effect on the way the app behaves in that it's no longer available when the user is offline, and the app will run much slower. So not something we should simply do transparently. What we *could* do, is to show the user UI when he/she attempts to start the app which says something like "There was a problem downloading the app which means that it won't function like normal. Want to run the app from the website instead?" with a "run from website" button. That might be pretty complex to do though. So not sure if it's worth spending time on for initial release.
(In reply to Jonas Sicking (:sicking) from comment #8) > That might be pretty complex to do though. So not sure if it's worth > spending time on for initial release. I agree with not adding complexity there. But we may just add a new installState that would let the UI know that the download failed so it could try to do an update to download again.
isn't .installStatus="pending", .downloadError!=null and .downloading=false enough?
(In reply to Jonas Sicking (:sicking) from comment #10) > isn't .installStatus="pending", .downloadError!=null and .downloading=false > enough? Yep, I though about that while biking home. I should bike more!
Created attachment 668030 [details] [diff] [review] patch v2 Updated patch to set .downloading correctly when a download error occurs.
This still does not work on latest-inbound (10/05), using the same STR in comment #0.
Aaron, if the appcache manifest has errors, this "failing" behavior is expected.
Yes. I'm not sure what the error is exactly. Last week it seemed like the failure was at: http://mxr.mozilla.org/mozilla-central/source/uriloader/prefetch/nsOfflineCacheUpdate.cpp#800 but the marketplace's manifest does have the CACHE MANIFEST line at its start: https://marketplace.mozilla.org/appcache/manifest.appcache
Some digging shows that we're basically not getting any data back from the server when we request the appcache manifest. Moving this over to the marketplace people to see if they know why? The download seems fine in Fennec/Firefox, so I'm suspicious there's something special going on here that confuses the server? The channel setup in Gecko is done here (if you want to look at some hearders/referrer stuff we set): http://mxr.mozilla.org/mozilla-central/source/uriloader/prefetch/nsOfflineCacheUpdate.cpp#310
Potch - Any ideas?
This seems suspiciously similar to bug 796820.
Wesley (or anyone, I suppose), do you know if this is caused by bug 796820?
It sounds like the same issue. I don't see any definitive conclusion about what caused bug 796820.
The root cause of the problem is being tracked in the dup of that bug cited above, which blocks ship. So let's use that bug to track what's the blocker. This bug inherently isn't the blocker. Removing the nom.
If this is a marketplace bug I'm going to need help understanding what you need from us. When I load https://marketplace.firefox.com/appcache/manifest.appcache I get data back - as far as I know that's all we can do. Are you saying it's not in the right format?
Works for me. Please reopen if problem still persists for you.