780415 - Failing to install a web app due to an external remote site issue outside of marketplace's control should flag the app for investigation to marketplace reviewers

Status: RESOLVED WORKSFORME

(Marketplace Graveyard :: Consumer Pages, defect)

Description

[Aaron Train [:aaronmt]]

E/GeckoConsole( 2049): [JavaScript Error: "[Exception... "Failure arg 0 [nsIDOMRequestService.fireError]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: jar:jar:file:///data/app/org.mozilla.fennec-1.apk!/omni.ja!/components/Webapps.js :: <TOP_LEVEL> :: line 156"  data: no]" {file: "jar:jar:file:///data/app/org.mozilla.fennec-1.apk!/omni.ja!/components/Webapps.js" line: 156}]

This might either a client issue or a site issue. On purchase of an application, the site status says 'Purchased', but there was no install. In order to begin the install procedure, I had to reload the page to get the 'Install' button. This is a sub-optimal experience.

--
Samsung Galaxy Nexus (Android 4.1.1)
Nightly (08/04)

Comment 1

[Aaron Train [:aaronmt]]

Changing the summary to reflect further problem. Purchased applications are not installing off the market. On tap of the install button does nothing. No errors in console. This may or may not be a client issue.

I am using the production server @ http://marketplace.mozilla.org

Comment 2

[Aaron Train [:aaronmt]]

This is the application I just purchased but can not install: https://marketplace.mozilla.org/en-US/app/scrum/?src=mkt-search

Comment 3

[Aaron Train [:aaronmt]]

So it looks like I just so happened to pick an application where the host could not be reached.

I just purchased and installed NovaSkin [1] just fine.

In any case, there should either a message on the market here or have an error shown in the client. (I just threw out a dollar for an application that does not exist?)

[1] https://marketplace.mozilla.org/en-US/app/novaskin/?src=mkt-search

Comment 4

[Jason Smith [:jsmith]]

Sounds like a dup of bug 776677 if we're talking about improving error messages.

Comment 5

[Aaron Train [:aaronmt]]

Agreed since this is the xhr NETWORK_ERROR.

Comment 6

[Christopher Van Wiemeersch [:cvan]]

The Marketplace should disable paid apps (and free apps) whose manifests that cannot be reached. I'm not sure how this is a dupe of bug 776677.

Comment 7

[Jason Smith [:jsmith]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #6)
> The Marketplace should disable paid apps (and free apps) whose manifests
> that cannot be reached. I'm not sure how this is a dupe of bug 776677.

I think the dupe was put in place from the error messages, but I agree that the proposal for removing or say, flagging apps as "problematic." Let's reopen this and move this to marketplace consumer pages. We should do something about this, as this is definitely possible to happen with free and paid apps.

Comment 8

[Jason Smith [:jsmith]]

Took a shot at rewording the title to attack the core piece of the problem - we need to handle the process of when a user possibly discovers a "broken" app.

So what's the best process to handle this then? Take this use case:

1. I find awesome app X
2. I try to install the web app
3. App reports some error that's not in marketplace's control (e.g. app host not reached, manifest syntax is not right)

What happens here? Possible ideas for resolutions:

1. Flag the app in a review queue to the marketplace review team
2. Automatic removal of the app from public consumer pages
3. Send an automated email to the app developer

(2) seems drastic, although could be needed if the problem is consistently happening. (1) seems reasonable, but possibly after N number of occurrences. (3) seems useful to include as well.

Comment 9

[Jason Smith [:jsmith]]

Nominating for basecamp - It's definitely possible for users to come across apps on marketplace that have problems that are not in marketplace's direct control. QA testing has already shown this to occur sometimes (I've hit this a couple of times on desktop, Aaron just hit it on mobile). We need a process to be able to handle this situation, as we need to maintain a marketplace of "good" apps that are "useful." Taking the risk to not have an automated process in place risks possible cases for some population of "broken" apps in our marketplace, which promotes a bad user experience to end consumers that consume our apps. 

Note that I do know our reviews process does help with this situation, but I don't think that's enough to handle this problem. Something more automated makes sure that we can respond to this problem quickly and take the appropriate action.

Comment 10

[Aaron Train [:aaronmt]]

Thanks for adding additoinal thought Jason. As for the error in comment #0, Wes/Mark, can we fix that?

Comment 11

[Wesley Johnston (:wesj)]

I need to look more into if these types of errors actually make it to us.

I think they fire on the request object(/promise?) itself. I'm not sure we can get at them in Fennec. If they do, we can show an error toast or something.

Comment 12

[[:fabrice] Fabrice Desré]

(In reply to Wesley Johnston (:wesj) from comment #11)
> I need to look more into if these types of errors actually make it to us.
> 
> I think they fire on the request object(/promise?) itself. I'm not sure we
> can get at them in Fennec. If they do, we can show an error toast or
> something.

That's correct, we don't notify chrome for such errors, only the content. We could fire an observer notification if needed to get it catched by fennec.

Comment 13

[krupa raj[:krupa]]

(In reply to Jason Smith [:jsmith] from comment #9)
> Nominating for basecamp - It's definitely possible for users to come across
> apps on marketplace that have problems that are not in marketplace's direct
> control. QA testing has already shown this to occur sometimes (I've hit this
> a couple of times on desktop, Aaron just hit it on mobile). We need a
> process to be able to handle this situation, as we need to maintain a
> marketplace of "good" apps that are "useful." Taking the risk to not have an
> automated process in place risks possible cases for some population of
> "broken" apps in our marketplace, which promotes a bad user experience to
> end consumers that consume our apps. 
> 
> Note that I do know our reviews process does help with this situation, but I
> don't think that's enough to handle this problem. Something more automated
> makes sure that we can respond to this problem quickly and take the
> appropriate action.

We already do this. Everyday a cron runs which flags apps with major changes or issues(like manifest 404'ing) to a re-reveiw queue. It was agreed that it will be a bad idea to "disable" the app prematurely. The reviewers can disable it manually if they find the app faulty.

Comment 14

[Jason Smith [:jsmith]]

Okay. In that case, I'll resolve this as worksforme then.

Comment 15

[Aaron Train [:aaronmt]]

(In reply to krupa raj 82[:krupa] from comment #13)
> (In reply to Jason Smith [:jsmith] from comment #9)
> We already do this. Everyday a cron runs which flags apps with major changes
> or issues(like manifest 404'ing) to a re-reveiw queue. It was agreed that it
> will be a bad idea to "disable" the app prematurely. The reviewers can
> disable it manually if they find the app faulty.

It still allowed me to throw out a dollar into the ether and that is unacceptable.

Comment 16

[krupa raj[:krupa]]

> It still allowed me to throw out a dollar into the ether and that is
> unacceptable.

We allow automatic refunds for the first 30 mins for such cases. I know that it is not ideal but (automatically) disabling apps whenever service is down will lead to developer frustration.

Comment 17

[Aaron Train [:aaronmt]]

This should block '1.0'.

Comment 18

[Wil Clouser [:clouserw]]

What are the next steps in this bug?  It sounds like the automatic refund feature solves the (rare) situation where this would occur.

Comment 19

[Christopher Van Wiemeersch [:cvan]]

(In reply to Wil Clouser [:clouserw] from comment #18)
> What are the next steps in this bug?  It sounds like the automatic refund
> feature solves the (rare) situation where this would occur.

The easiest fix is to check that the manifest can be reached after clicking the purchase button but *before* initiating purchase.

Comment 20

[Wil Clouser [:clouserw]]

(In reply to Chris Van Wiemeersch [:cvan] from comment #19)
> (In reply to Wil Clouser [:clouserw] from comment #18)
> > What are the next steps in this bug?  It sounds like the automatic refund
> > feature solves the (rare) situation where this would occur.
> 
> The easiest fix is to check that the manifest can be reached after clicking
> the purchase button but *before* initiating purchase.

That sounds like something the client should be doing before it pops open the payment window.  If we did it in the marketplace it would be a lot of extra traffic and also only work for our marketplace.

Comment 21

[Wil Clouser [:clouserw]]

i'm closing this bug based on comments 18-20.