797048 - Firefox Marketplace does not launch from the Apps Dashboard

Status: RESOLVED WORKSFORME

(Marketplace Graveyard :: General, defect)

Description

[Aaron Train [:aaronmt]]

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)

Comment 1

[Aaron Train [:aaronmt]]

Even on new cold-start (fennec relaunching after quit), the shortcut in the apps dashboard is a dud.

Comment 2

[Wesley Johnston (:wesj)]

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?

Comment 3

[Wesley Johnston (:wesj)]

I added a little logging to the AppcacheObserver to make sure it was being called, and then noticed some errors showing up during the app install:

12:18:57 PM - wesj: E/GeckoConsole(30226): [JavaScript Error: "TypeError: Cc[aContract] is undefined" {file: "resource://gre/modules/Webapps.jsm" line: 685}]
12:18:57 PM - wesj: E/GeckoConsole(30226): [JavaScript Error: "TypeError: aMm is undefined" {file: "resource://gre/modules/Webapps.jsm" line: 1188}]
12:18:57 PM - wesj: E/GeckoConsole(30226): updateStateChanged (added by me)
12:18:57 PM - wesj: E/GeckoConsole(30226): Error (added by me)
12:18:57 PM - wesj: E/GeckoConsole(30226): [JavaScript Error: "ReferenceError: installState is not defined" {file: "jar:jar:file:///data/app/org.mozilla.fennec_wesj-1.apk!/omni.ja!/components/Webapps.js" line: 494}]

Comment 4

[Jason Smith [:jsmith]]

This is likely a regression from the install/update API landing.

Comment 5

[Jason Smith [:jsmith]]

(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.

Comment 6

[Wesley Johnston (:wesj)]

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

Comment 7

[[:fabrice] Fabrice Desré]

Attachment: 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.

Comment 8

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

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.

Comment 9

[[:fabrice] Fabrice Desré]

(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.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

isn't .installStatus="pending", .downloadError!=null and .downloading=false enough?

Comment 11

[[:fabrice] Fabrice Desré]

(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!

Comment 12

[[:fabrice] Fabrice Desré]

Attachment: patch v2

Updated patch to set .downloading correctly when a download error occurs.

Comment 13

[[:fabrice] Fabrice Desré]

https://hg.mozilla.org/integration/mozilla-inbound/rev/4f7a6eba1140

Comment 14

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/4f7a6eba1140

Comment 15

[Aaron Train [:aaronmt]]

This still does not work on latest-inbound (10/05), using the same STR in comment #0.

Comment 16

[[:fabrice] Fabrice Desré]

Aaron, if the appcache manifest has errors, this "failing" behavior is expected.

Comment 17

[Wesley Johnston (:wesj)]

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

Comment 18

[Wesley Johnston (:wesj)]

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

Comment 19

[Jason Smith [:jsmith]]

Potch - Any ideas?

Comment 20

[Christopher Van Wiemeersch [:cvan]]

This seems suspiciously similar to bug 796820.

Comment 21

[Wil Clouser [:clouserw]]

Wesley (or anyone, I suppose), do you know if this is caused by bug 796820?

Comment 22

[Wesley Johnston (:wesj)]

It sounds like the same issue. I don't see any definitive conclusion about what caused bug 796820.

Comment 23

[Jason Smith [:jsmith]]

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.

Comment 24

[Wil Clouser [:clouserw]]

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?

Comment 25

[Christopher Van Wiemeersch [:cvan]]

Works for me. Please reopen if problem still persists for you.