Firefox Marketplace does not launch from the Apps Dashboard

RESOLVED WORKSFORME

Status

Marketplace
General
RESOLVED WORKSFORME
5 years ago
5 years ago

People

(Reporter: aaronmt, Assigned: fabrice)

Tracking

({regression})

ARM
Android
regression
Points:
---

Firefox Tracking Flags

(firefox18-)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

5 years ago
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)
(Reporter)

Comment 1

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

Updated

5 years ago
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:

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?
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 - 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.
(Assignee)

Updated

5 years ago
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:

https://marketplace.mozilla.org/appcache/manifest.appcache
(Assignee)

Comment 7

5 years ago
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.
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.
(Assignee)

Comment 9

5 years ago
(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?
(Assignee)

Comment 11

5 years ago
(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!
(Assignee)

Updated

5 years ago
Attachment #667658 - Flags: feedback?(wjohnston) → review?(wjohnston)
(Assignee)

Updated

5 years ago
Attachment #667658 - Flags: review?(wjohnston)
(Assignee)

Comment 12

5 years ago
Created attachment 668030 [details] [diff] [review]
patch v2

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+
(Assignee)

Comment 13

5 years ago
https://hg.mozilla.org/integration/mozilla-inbound/rev/4f7a6eba1140
https://hg.mozilla.org/mozilla-central/rev/4f7a6eba1140
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 18
(Reporter)

Comment 15

5 years ago
This still does not work on latest-inbound (10/05), using the same STR in comment #0.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(Assignee)

Comment 16

5 years ago
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
tracking-firefox18: --- → +
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
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: ? → ---

Updated

5 years ago
Component: General → General
Product: Marketplace → Firefox for Android
Version: 1.0 → unspecified

Updated

5 years ago
status-firefox18: affected → ---
tracking-firefox18: + → -
Component: General → General
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 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.
Status: REOPENED → RESOLVED
Last Resolved: 5 years ago5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.