837960 - B2G should show better error to the user when the install/update download fails

Status: RESOLVED WONTFIX

(Core Graveyard :: DOM: Apps, defect)

Description

[Matt Basta [:basta]]

If the manifest can't be retrieved, the app should not silently fail to install.

- The user should be given a prompt, perhaps with an expander giving an optional technical reason.
- The app could continue to function as if the appcache was not present to begin with. The manifest could be stored locally without the appcache_path field, so subsequent updates would attempt to download it as if it was new.

The current behavior is unacceptable as a permanent solution. I've heard from too many people whose apps aren't installing and they can't figure out why. Even our reviewers have a difficult time diagnosing this issue.

The validator currently checks for this, but only if the appcache_path is a full URL with the domain and protocol. This is being tracked in bug 837947. Not all developers know about the validator, and this doesn't help users who encounter apps with bad appcache_paths.

Comment 1

[Jason Smith [:jsmith]]

Silently fail? Which app?

Technically right now, we fail to install in this case and should report an error message to the user.

As for item [2], I believe it's by design that we fail fast.

Comment 2

[[:fabrice] Fabrice Desré]

There can be different reasons for an appcache manifest to not be retrievable. When it's a syntactically correct uri that just points to something non-existent, we consider that the application is in a "pending" installation state, which looks right to me. At least, it's far from being "unacceptable". Note that we also need to download *all* the resources from an appcache for it to be "installed". 

Storing the manifest without an app_cache field is a bad idea: if the app is designed to be used offline, the current code prevents it to launch, which is good. You solution would mean that we launch it but retrieve data at first launch, when the user is on a potentially slow/expensive data connection.

Comment 3

[Mounir Lamouri (:mounir)]

(In reply to Fabrice Desré [:fabrice] from comment #2)
> Storing the manifest without an app_cache field is a bad idea: if the app is
> designed to be used offline, the current code prevents it to launch, which
> is good. You solution would mean that we launch it but retrieve data at
> first launch, when the user is on a potentially slow/expensive data
> connection.

Can't we simply show the app as if there was no appcache for it? What do we do for application that doesn't have an application cache? If we allow installing an application that has no application cache but do not install an application with an incorrect appcache manifest, I agree with Matt, this is inconsistent.

Comment 4

[Julien Wajsberg [:julienw]]

Note also that there are always logs when an app is not installing correctly.

Comment 5

[[:fabrice] Fabrice Desré]

My rationale is that if the author specifies an appcache_path in it's manifest, this is because it's important for a good app experience. This is a way to build an offline app if you don't want to do a packaged app, so we try to treat the appcache download the same way we treat the package download : if that fails, you are in "pending" install state. I agree that you could still launch the app but we may then do unexpected network access.

Nothing prevents the author to *not* specify the appcache_path in the manifest, but still use it in the webpage. That will be a different install/first launch experience for the user.

Comment 6

[Jason Smith [:jsmith]]

Trying to figure out if we've agreed resolution on this if this is a bug or intended behavior.

Fabrice and Julien's comments indicate this is expected behavior. I don't have a strong opinion on this one.

Matt and Mounir - Where do you guys stand based on Julien and Fabrice's comments?

Comment 7

[Julien Wajsberg [:julienw]]

Post-v1.0 we will display better errors for the user and/or the developer but we believed this is enough for v1.0.

We might have been able to do something better if we had known that the deadline wasn't really January 15th ;)

Comment 8

[Matt Basta [:basta]]

I just tested this on a phone that has a more recent build than the phone I've been testing on. "Older" builds (and the latest version of the simulator) both fail completely silently, giving the user no indication that the app was not installed.

On the recent build that I tested the behavior on, the only indication that the installation failed is a notification that says "<app name> download failed".

- This makes it seem like the user did something wrong, when in fact it is a problem caused by the app developer or the service that the app is running on.
- The user is given no choice in the matter. There is no dialog that says, "The app does not have offline support at this time. Do you wish to install anyway?"
- There is no feedback about what's wrong with the appcache. I.e.: the only logcat'd error is APP_CACHE_DOWNLOAD_ERROR, regardless of what's wrong.

I don't believe this behavior is the appropriate behavior for the final product. Whether that's 1.0 or 1.1 or beyond, I don't know, but I think that it's something that should change.

Comment 9

[Lisa Brewster [:adora]]

+1 to Comment 8.  There's perfectly valid functionality on the other side of that error message, as long as users know what their options are and caveats (network access, degraded performance) are clear.

Comment 10

[Jason Smith [:jsmith]]

Got more clarity on what the issue is here.

Two issues:

* The download failed/stopped message tells the user that something failed, but does not really do any value to the user on why it failed (may confuse user into thinking it's their fault vs. server's fault).

* The appcache error reported in logcat indicates there was an error during install, but doesn't indicate what failed. Syntax error in the appcache manifest? 404 on the appcache manifest?

Comment 11

[Jason Smith [:jsmith]]

Sounds like we've got two bugs here. I'm going to split this bug up into two parts and close this one out.

Comment 12

[[:fabrice] Fabrice Desré]

(In reply to Matt Basta [:basta] from comment #8)

> On the recent build that I tested the behavior on, the only indication that
> the installation failed is a notification that says "<app name> download
> failed".
> 
> - This makes it seem like the user did something wrong, when in fact it is a
> problem caused by the app developer or the service that the app is running
> on.

I don't understand why "<app name> download failed" looks like an user error. Do you feel you did something bad when a webpage 404 in your browser? I sure don't.

> - The user is given no choice in the matter. There is no dialog that says,
> "The app does not have offline support at this time. Do you wish to install
> anyway?"

It is installed. Just not usable right now, waiting for the download to be retried.

> - There is no feedback about what's wrong with the appcache. I.e.: the only
> logcat'd error is APP_CACHE_DOWNLOAD_ERROR, regardless of what's wrong.

That's a totally different issue.

Comment 13

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #12)
> (In reply to Matt Basta [:basta] from comment #8)
> 
> > - There is no feedback about what's wrong with the appcache. I.e.: the only
> > logcat'd error is APP_CACHE_DOWNLOAD_ERROR, regardless of what's wrong.
> 
> That's a totally different issue.

Broke out bug 840250 for this.

Comment 14

[Julien Wajsberg [:julienw]]

FYI the handling of install errors was done in Bug 816448. There are a bunch of new errors that were implemented after this and that will trigger the generic "download stopped" message. This is very easily fixable if that's an issue.

About the appcache errors, I believe there are also appcache logs that say what's wrong. A developer can see something is wrong by merely using his application in Firefox. We believe the final user will rarely see the error as the developer will already have fixed that. Of course, some unforeseen errors (eg: network error) can happen but then there is nothing the user can do anyway.

So: if you want that we change how specific errors trigger a specific existing error message, we can do that. Anything else is a product decision and I'm quite sure this will be declined.

Comment 15

[Jason Smith [:jsmith]]

Josh - Can you provide input on the discussion above that targets this area:

The download failed/stopped message tells the user that something failed, but does not really do any value to the user on why it failed (may confuse user into thinking it's their fault vs. server's fault).

I'm trying to figure out what is the "right" bug to file here and the UX implications here. Do you have some insight here?

After we get this open item resolved, I think we can close this and use bug 840250 and a different bug if needed for the item above.

Comment 16

[Mounir Lamouri (:mounir)]

(In reply to Fabrice Desré [:fabrice] from comment #5)
> My rationale is that if the author specifies an appcache_path in it's
> manifest, this is because it's important for a good app experience. This is
> a way to build an offline app if you don't want to do a packaged app, so we
> try to treat the appcache download the same way we treat the package
> download : if that fails, you are in "pending" install state. I agree that
> you could still launch the app but we may then do unexpected network access.

This is a lose / lose situation. For the developer, having the user not using his/her app because there was a typo in the app cache manifest is worst than having the user using the network at first run. For the user, not being able to install the app is worse than having to use the network to use it.

In addition, the app manifest could be set for a few assets, without making the app fully offline and the app data would have been downloaded at install time, forbidding installation because the app might be launch at another moment doesn't make much sense because very likely the app will be launch for the first time just after the installation. 

> Nothing prevents the author to *not* specify the appcache_path in the
> manifest, but still use it in the webpage. That will be a different
> install/first launch experience for the user.

Indeed, but making our app platform too strict isn't going to help us. We should be fault tolerant and fallback to sane defaults. This is what the Web Platform do most of the time: incorrect values are simply ignored.

Comment 17

[Josh Carpenter [:jcarpenter]]

(In reply to Jason Smith [:jsmith] from comment #15)
> Josh - Can you provide input on the discussion above that targets this area:
> 
> The download failed/stopped message tells the user that something failed,
> but does not really do any value to the user on why it failed (may confuse
> user into thinking it's their fault vs. server's fault).
> 
> I'm trying to figure out what is the "right" bug to file here and the UX
> implications here. Do you have some insight here?
> 
> After we get this open item resolved, I think we can close this and use bug
> 840250 and a different bug if needed for the item above.

Let's talk usability heuristics. Here's an oldie-but-a-goodie from Mr. Norman in the early 80's:

> Feedback: The state of the system should be clearly available to the user, 
> ideally in a form that is unambiguous and that makes the set of options 
> readily available . . .

Or, more succinctly: 

> Help users recognize, diagnose, and recover from errors

Per Matt's suggestion in comment 8, a vague error frustrates the user. PC LOAD LETTER. 

My recommendations are: 

1. Don't fail in the first place: I defer to Mounir, Fabrice et al on the app manifest question and what constitutes failure.
2. If there is a failure, communicate it to the user: use banners or prompts to explain to the user what happened, and when possible provide them with means to rectify the situation (eg: a tip on how to try downloading again).

There's some overlap here with bug #839491, I think.

Comment 18

[Julien Wajsberg [:julienw]]

(In reply to Josh Carpenter [:jcarpenter] from comment #17)

> There's some overlap here with bug #839491, I think.

True for errors with packaged apps, but we never "unrecoverably fail" for appcache errors, because (for now) we don't know the underlying cause.

Comment 19

[Sylvestre Ledru [:Sylvestre]]

Mass closing as we are no longer working on b2g/firefox os.

Comment 20

[Sylvestre Ledru [:Sylvestre]]

Mass closing as we are no longer working on b2g/firefox os.