Closed Bug 839491 Opened 12 years ago Closed 10 years ago

Indicate that an app cannot be installed when in an unrecoverable state on the homescreen

Categories

(Firefox OS Graveyard :: Gaia::Homescreen, defect)

ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

(blocking-b2g:-, b2g18+, b2g-v2.0 fixed, b2g-v2.1 fixed)

RESOLVED FIXED
2.0 S4 (20june)
blocking-b2g -
Tracking Status
b2g18 + ---
b2g-v2.0 --- fixed
b2g-v2.1 --- fixed

People

(Reporter: julienw, Assigned: kgrandon)

References

Details

(Keywords: late-l10n, Whiteboard: [systemsfe])

Attachments

(6 files, 1 obsolete file)

For unrecoverable errors (for example: the packaged zip is invalid), the platform sets downloadAvailable to false. We should at least not restart a download when downloadAvailable is false, and at best we should also display another icon to make it clear that there is an unrecoverable error. Indeed in this case the user can only uninstall the app.
Blocks: app-install
Josh, what do you think of the icon proposition ?
No longer blocks: app-install
Flags: needinfo?(jcarpenter)
Blocks: app-install
This will need Bug 838823 checked in otherwise we won't be able to restart any download.
Depends on: 838823
(In reply to Julien Wajsberg [:julienw] from comment #0) > For unrecoverable errors (for example: the packaged zip is invalid), the > platform sets downloadAvailable to false. What if the user wants to try to download the app again? Are we sure we want to prevent them from doing so? > We should at least not restart a download when downloadAvailable is false, > and at best we should also display another icon to make it clear that there > is an unrecoverable error. I don't have all the details here, but I'd think we'd want to at least give the user an explanation of what went wrong, and the option to either "Try Again" or "Cancel" (the later being synonymous with deleting the app). > Indeed in this case the user can only uninstall the app. What if they paid for it, though? Shouldn't we provide some means of restarting the process?
Flags: needinfo?(jcarpenter)
(In reply to Josh Carpenter [:jcarpenter] from comment #3) Those are very valid questions indeed. > (In reply to Julien Wajsberg [:julienw] from comment #0) > > For unrecoverable errors (for example: the packaged zip is invalid), the > > platform sets downloadAvailable to false. > > What if the user wants to try to download the app again? Are we sure we want > to prevent them from doing so? This was initially done for the update case, where the app will get downloadAvailable again at the next "check for update" cycle. > > We should at least not restart a download when downloadAvailable is false, > > and at best we should also display another icon to make it clear that there > > is an unrecoverable error. > > I don't have all the details here, but I'd think we'd want to at least give > the user an explanation of what went wrong, and the option to either "Try > Again" or "Cancel" (the later being synonymous with deleting the app). > > > Indeed in this case the user can only uninstall the app. > > What if they paid for it, though? Shouldn't we provide some means of > restarting the process? That is painfully right. I'd say this will stay like this un v1.0 anyway but we may think of something better for v1.1. Fabrice, any additional thought ?
Flags: needinfo?(fabrice)
If the user payed the app, the store should keep track of the user <-> receipt. So in the worst case, uninstalling the app and reinstalling should work (ie the store should not charge the user twice).
Flags: needinfo?(fabrice)
Hi guys, thanks for the additional details. Instead of an icon, I recommend we use a full prompt. It's a bit intrusive, but I think we need to err on the side of clear communication if there are potentially paid apps involved. How about: 1.) User taps install 2.) App downloads 3.) App finishes downloading and system begins installation 4.) Unrecoverable error is detected 5.) Prompt appears, with: - Title: [AppName] failed to install - Body: An error prevented [AppName] from installing. Visit the original installation source to try again. - Button: "Cancel install" Pressing the button closes the prompt, removes the icon from the grid, and removes the app from the app registry (presumably). Does that make sense?
Josh, what do you think could be eventuadone in the v1.0.1 timeframe ?
*eventually done
Just found Bug 821209 when digging into my bug list. Let's say Bug 821209 is for a short-term fix, and this one for a long-term fix.
Depends on: 821209
Thanks Julien, I commented in bug 821209. I realize this is probably a relatively unlikely edge case, but even still I think we need to include a prompt to the user that explains what the heck just happened to their install. Having it disappear without any explanation isn't good enough, IMO.
Ok, I understand the reasoning. What I don't like with the dialog is that there will be new l10n strings... But it should not be difficult to do. In this case I'll dupe Bug 821209 into this one as that's where we have the most recent information.
No longer depends on: 821209
blocking-b2g: --- → leo?
blocking-b2g: leo? → -
Blocks: b2g-apps-v1-next
No longer blocks: app-install
No longer blocks: b2g-apps-v1-next
The platform side was fixed but we still have the bug in gaia... lets fix it on the vericalhome. There are some conditions in which the platform decides that an app cannot be downloaded (ever). The only action here is to uninstall the app. We should make this obvious to the user and when tapping ideally prompt them to uninstall the app. This is easy to indicate now that we have done the work for the other states (paused, canceled, recoverable error). I don't think we can get this in for 2.0 (but surely 2.1) since it likely requires new strings.
Flags: needinfo?(pla)
Summary: When installing an app, we should not let the user restart a download when the platform resets downloadAvailable to false for unrecoverable errors → Indicate that an app cannot be installed when in an unrecoverable state on the homescreen
Assignee: nobody → jlal
This package contains the unrecoverable state icon (red circle + landed rocket).
Flags: needinfo?(pla)
Proposal for prompt text: Title: "Remove Application" Body: "Cannot install application because of an unrecoverable error with the file. Do you want to remove the application?" Buttons: "Cancel" " Remove" Let me know if this makes sense to everyone, if not, I can revise it.
Updated text Title: "Remove Application" Body: "Cannot install application due to an unrecoverable error. Please try downloading again. The application will be removed." Buttons: "Confirm"
Attachment #8443781 - Flags: review?(kgrandon)
Attachment #8443784 - Flags: ui-review?(jsavory)
Attachment #8443789 - Flags: ui-review?(jsavory)
Comment on attachment 8443781 [details] [review] https://github.com/mozilla-b2g/gaia/pull/20830 I did't see anything awful immediately, but let's wait for the big bug to land first. Testing it now.
Attachment #8443781 - Flags: review?(kgrandon) → review+
Comment on attachment 8443781 [details] [review] https://github.com/mozilla-b2g/gaia/pull/20830 This is required for the vertical homescreen and late-l10n. Requesting approval as this will land today, so we can uplift.
Attachment #8443781 - Flags: approval-gaia-v2.0?(bbajaj)
Attachment #8443784 - Flags: ui-review?(jsavory) → ui-review+
Attachment #8443789 - Flags: ui-review?(jsavory) → ui-review-
Attachment #8443781 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
Just to clarify - Attachment #8443789 [details] was ui-reivew minused because attachment #8443809 [details] replaces it with the correct text.
Attached file Github pull request
Rebased pull request
Assignee: jlal → kgrandon
Attachment #8443781 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Comment on attachment 8443864 [details] [review] Github pull request Whoops, this already had approval 2.0, but the old attachment is obsoleted. This is a new patch to address rebasing after recent landings. Can you please carry the A+? Thanks!
Attachment #8443864 - Flags: approval-gaia-v2.0?(bbajaj)
Comment on attachment 8443864 [details] [review] Github pull request Clearing until we have a green build.
Attachment #8443864 - Flags: approval-gaia-v2.0?(bbajaj)
Hey James - I haven't been able to get a green build yet, but I have an attachment here with a rebased version that you may want to take. Since it's not in and uplifted today I'm not sure what that means for strings. I suppose we should still try to move forward with a green build and see if we can get it. Otherwise we may need to rethink the UX to not need strings.
Flags: needinfo?(jlal)
Comment on attachment 8443864 [details] [review] Github pull request Turns out my last try run was a success over night, let's land this and request uplift.
Attachment #8443864 - Flags: review+
Flags: needinfo?(jlal)
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Comment on attachment 8443864 [details] [review] Github pull request This is needed for the vertical homescreen.
Attachment #8443864 - Flags: approval-gaia-v2.0?(bbajaj)
Attachment #8443864 - Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
Whiteboard: [systemsfe]
Target Milestone: --- → 2.0 S4 (20june)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: