Closed
Bug 821209
Opened 12 years ago
Closed 12 years ago
When post-download checks (e.g. security checks) on a packaged app fail, the app is left on the home screen
Categories
(Firefox OS Graveyard :: Gaia::Homescreen, defect, P3)
Firefox OS Graveyard
Gaia::Homescreen
Tracking
(b2g18+)
RESOLVED
DUPLICATE
of bug 839491
Tracking | Status | |
---|---|---|
b2g18 | + | --- |
People
(Reporter: briansmith, Assigned: julienw)
Details
(Whiteboard: UX-P2, interaction)
+++ This bug was initially created as a clone of Bug #821207 +++
I understand that we intentionally leave apps on the home screen when installation fails due to *network* errors, so that the user can resume the download by tapping on the app icon.
However, when installation of a packaged app fails because of some errors during the post-download checks, it is unclear if we should keep it on the home screen or delete it.
The particular case I noticed was when I had mistyped "nsIX509CertDB" in part 4 of bug 772365, which caused an unexpected and unhandled exception to be raised. I am not sure what happens exactly for *expected* types of errors (e.g. invalid "type" property in the manifest).
Updated•12 years ago
|
Component: DOM: Apps → Gaia::Homescreen
Product: Core → Boot2Gecko
Version: Trunk → unspecified
Comment 1•12 years ago
|
||
Josh what would be the right behaviour in this case ?
Flags: needinfo?(jcarpenter)
Comment 2•12 years ago
|
||
Hmm, very good question. We have a few different options. The right approach depends on:
* Would there be any value in a "try again" option?
* Will there be _anything_ the user can do to fix the situation when the check fails?
Jonas, I'm not sure if you're the right person to answer those?
At a minimum we should present a prompt that explains the error to the user.
Flags: needinfo?(jcarpenter) → needinfo?(jonas)
Comment 3•12 years ago
|
||
I do think this should block, fwiw. We need to handle this situation some how.
Whiteboard: UX-P2, interaction
Updated•12 years ago
|
Assignee: nobody → felash
blocking-basecamp: ? → +
Priority: -- → P2
Assignee | ||
Comment 4•12 years ago
|
||
josh> We already present a generic prompt to the user in the system app (Bug 816448). It think that's enough if the user can't do much to recover this.
In Bug 816448 we added the distinction between different types of error (download errors, install errors, INSUFFICIENT_STORAGE error, unknown), maybe we can do the same in the homescreen :
- download errors: current behaviour
- install errors: remove the icon
- unknown errors: I let you choose; it could happen if the platform implements a new error and we don't catch this on the gaia side, but this should not happen.
Comment 5•12 years ago
|
||
FYI, we just got 2 new errors from the signing code for packaged apps: CERTDB_ERROR and INVALID_SIGNATURE.
Assignee | ||
Comment 6•12 years ago
|
||
fabrice> which bug ? is there a bug opened to support them in gaia ?
Comment 7•12 years ago
|
||
Bug 772365, Part 4. I don't know of any gaia bug.
(In reply to Josh Carpenter [:jcarpenter] from comment #2)
> Hmm, very good question. We have a few different options. The right approach
> depends on:
>
> * Would there be any value in a "try again" option?
In theory we should only get in to this situation when there's a bug in the marketplace. It can also happen if an "evil", or more likely, a misinformed 3rd party marketplace tries to do something it's not allowed to do.
This can get fixed eventually on the serverside, but retrying immediately has little value. More likely is that it could work if the user tries again a few days later.
> * Will there be _anything_ the user can do to fix the situation when the
> check fails?
Nope.
I personally don't think this is a blocker. This should be rare enough that it's not something to worry about for v1. The intuitive thing for the user to do is to delete the app, or to try to reinstall it, which basically gives the desired behavior.
blocking-basecamp: + → ?
Flags: needinfo?(jonas)
Assignee | ||
Comment 9•12 years ago
|
||
Jonas> this could also happen if a 3rd-party developer proposes to install its app from its own website.
However I agree this is not a blocker, the user can still delete the added icon if he wants to.
Updated•12 years ago
|
blocking-basecamp: ? → ---
blocking-kilimanjaro: --- → +
Priority: P2 → P3
Comment 10•12 years ago
|
||
Please explicitly minus bugs. Do not unnom bugs. Thanks.
blocking-basecamp: --- → ?
Comment 11•12 years ago
|
||
It's not a minused bug it's just postponed after January 15th. This is the reason why we used kilimandjaro tag.
blocking-basecamp: ? → ---
Updated•12 years ago
|
blocking-kilimanjaro: + → ---
tracking-b2g18:
--- → +
Assignee | ||
Comment 12•12 years ago
|
||
I proposed something in Comment 4.
Now the platform also sets the "downloadAvailable" property to false when it thinks the error is unrecoverable so we should definitely use that instead.
Josh what do you think about removing the icon as a v1 solution ?
Flags: needinfo?(jcarpenter)
Comment 13•12 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #12)
> I proposed something in Comment 4.
>
> Now the platform also sets the "downloadAvailable" property to false when it
> thinks the error is unrecoverable so we should definitely use that instead.
>
> Josh what do you think about removing the icon as a v1 solution ?
I don't think we can remove the icon without explaining to the user what happened. Imagine this sequence:
1.) Go to Marketplace
2.) Purchase app, tap "Install"
3.) See download indicator appear in Status Bar, and downloading activity notification appear Notification Center
4.) Download completes! Yay! It took forever over my Sao Paulo data connection, but it was worth it!
5.) Go to Home screen. No app.
6.) Crying
I realize 1.0.1 is looming, but would a prompt along the lines of what I suggest in bug #839491 be excessively difficult to implement? It would do the same thing that you're proposing (remove the icon), with just the addition of a standard system prompt dialogue with title, body, and one button.
Flags: needinfo?(jcarpenter)
Assignee | ||
Updated•12 years ago
|
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•