Closed Bug 797048 Opened 8 years ago Closed 7 years ago

Firefox Marketplace does not launch from the Apps Dashboard


(Marketplace Graveyard :: General, defect)

Not set



Tracking Status
firefox18 - ---


(Reporter: aaronmt, Assigned: fabrice)


(Keywords: regression)


(1 file, 1 obsolete file)

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.
Component: General → Web Apps
QA Contact: aaron.train
This seems to be a problem with some changes in dom/apps/WebApps.jsm. We're failing at:

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?
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}]
This is likely a regression from the install/update API landing.
Keywords: regression
(In reply to Jason Smith [:jsmith] from comment #4)
> This is likely a regression from the install/update API landing.

Tracking bug for reference - Any resolved fixed bug under that bug in the depends list could have caused this regression.
Assignee: nobody → fabrice
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:
Attached patch patch (obsolete) — Splinter Review
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.
Attachment #667658 - Flags: feedback?(wjohnston)
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!
Attachment #667658 - Flags: feedback?(wjohnston) → review?(wjohnston)
Attachment #667658 - Flags: review?(wjohnston)
Attached patch patch v2Splinter Review
Updated patch to set .downloading correctly when a download error occurs.
Attachment #667658 - Attachment is obsolete: true
Attachment #668030 - Flags: review?(wjohnston)
Attachment #668030 - Flags: review?(wjohnston) → review+
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18
This still does not work on latest-inbound (10/05), using the same STR in comment #0.
Resolution: FIXED → ---
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:

but the marketplace's manifest does have the CACHE MANIFEST line at its start:
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):
Component: Web Apps → General
Product: Firefox for Android → Marketplace
QA Contact: aaron.train
Target Milestone: Firefox 18 → ---
Version: Trunk → 1.0
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?
blocking-basecamp: --- → ?
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.
blocking-basecamp: ? → ---
Product: Marketplace → Firefox for Android
Version: 1.0 → unspecified
Product: Firefox for Android → Marketplace
Version: unspecified → 1.0
If this is a marketplace bug I'm going to need help understanding what you need from us.  When I load 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.
Closed: 8 years ago7 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.