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)

defect

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).
No longer blocks: 821211
Component: DOM: Apps → Gaia::Homescreen
Product: Core → Boot2Gecko
Version: Trunk → unspecified
Josh what would be the right behaviour in this case ?
Flags: needinfo?(jcarpenter)
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)
I do think this should block, fwiw. We need to handle this situation some how.
Whiteboard: UX-P2, interaction
Assignee: nobody → felash
blocking-basecamp: ? → +
Priority: -- → P2
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.
FYI, we just got 2 new errors from the signing code for packaged apps: CERTDB_ERROR and INVALID_SIGNATURE.
fabrice> which bug ? is there a bug opened to support them in gaia ?
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)
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.
blocking-basecamp: ? → ---
blocking-kilimanjaro: --- → +
Priority: P2 → P3
Please explicitly minus bugs. Do not unnom bugs. Thanks.
blocking-basecamp: --- → ?
It's not a minused bug it's just postponed after January 15th. This is the reason why we used kilimandjaro tag.
blocking-basecamp: ? → ---
blocking-kilimanjaro: + → ---
tracking-b2g18: --- → +
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)
Blocks: 839491
(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)
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
No longer blocks: 839491
You need to log in before you can comment on or make changes to this bug.