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)
Tracking
(blocking-b2g:-, 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)
(deleted),
application/zip
|
Details | |
(deleted),
image/png
|
jsavory
:
ui-review+
|
Details |
(deleted),
image/png
|
jsavory
:
ui-review-
|
Details |
(deleted),
image/png
|
Details | |
(deleted),
image/png
|
Details | |
(deleted),
text/x-github-pull-request
|
kgrandon
:
review+
bajaj
:
approval-gaia-v2.0+
|
Details |
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.
Updated•12 years ago
|
Blocks: app-install
Reporter | ||
Comment 1•12 years ago
|
||
Josh, what do you think of the icon proposition ?
No longer blocks: app-install
Flags: needinfo?(jcarpenter)
Updated•12 years ago
|
Blocks: app-install
Reporter | ||
Comment 2•12 years ago
|
||
This will need Bug 838823 checked in otherwise we won't be able to restart any download.
Depends on: 838823
Comment 3•12 years ago
|
||
(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)
Reporter | ||
Comment 4•12 years ago
|
||
(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)
Comment 5•12 years ago
|
||
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)
Comment 6•12 years ago
|
||
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?
Reporter | ||
Comment 7•12 years ago
|
||
Josh, what do you think could be eventuadone in the v1.0.1 timeframe ?
Reporter | ||
Comment 8•12 years ago
|
||
*eventually done
Reporter | ||
Comment 9•12 years ago
|
||
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.
Comment 10•12 years ago
|
||
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.
Reporter | ||
Comment 11•12 years ago
|
||
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.
Reporter | ||
Updated•12 years ago
|
blocking-b2g: --- → leo?
Updated•12 years ago
|
blocking-b2g: leo? → -
Updated•12 years ago
|
Updated•11 years ago
|
No longer blocks: b2g-apps-v1-next
Comment 13•10 years ago
|
||
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
Updated•10 years ago
|
Assignee: nobody → jlal
Comment 14•10 years ago
|
||
This package contains the unrecoverable state icon (red circle + landed rocket).
Flags: needinfo?(pla)
Comment 15•10 years ago
|
||
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.
Comment 16•10 years ago
|
||
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"
Comment 17•10 years ago
|
||
Attachment #8443781 -
Flags: review?(kgrandon)
Comment 18•10 years ago
|
||
Attachment #8443784 -
Flags: ui-review?(jsavory)
Comment 19•10 years ago
|
||
Attachment #8443789 -
Flags: ui-review?(jsavory)
Assignee | ||
Comment 20•10 years ago
|
||
Comment on attachment 8443781 [details]
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 21•10 years ago
|
||
Comment 22•10 years ago
|
||
Assignee | ||
Comment 23•10 years ago
|
||
Comment on attachment 8443781 [details]
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)
Updated•10 years ago
|
Attachment #8443784 -
Flags: ui-review?(jsavory) → ui-review+
Updated•10 years ago
|
Attachment #8443789 -
Flags: ui-review?(jsavory) → ui-review-
Updated•10 years ago
|
Attachment #8443781 -
Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
Comment 24•10 years ago
|
||
Just to clarify - Attachment #8443789 [details] was ui-reivew minused because attachment #8443809 [details] replaces it with the correct text.
Assignee | ||
Comment 25•10 years ago
|
||
Rebased pull request
Assignee | ||
Comment 26•10 years ago
|
||
Comment on attachment 8443864 [details]
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)
Assignee | ||
Comment 27•10 years ago
|
||
Comment on attachment 8443864 [details]
Github pull request
Clearing until we have a green build.
Attachment #8443864 -
Flags: approval-gaia-v2.0?(bbajaj)
Assignee | ||
Comment 28•10 years ago
|
||
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)
Assignee | ||
Comment 29•10 years ago
|
||
Comment on attachment 8443864 [details]
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)
Assignee | ||
Comment 30•10 years ago
|
||
Assignee | ||
Comment 31•10 years ago
|
||
Comment on attachment 8443864 [details]
Github pull request
This is needed for the vertical homescreen.
Attachment #8443864 -
Flags: approval-gaia-v2.0?(bbajaj)
Updated•10 years ago
|
Attachment #8443864 -
Flags: approval-gaia-v2.0?(bbajaj) → approval-gaia-v2.0+
Assignee | ||
Comment 32•10 years ago
|
||
status-b2g-v2.0:
--- → fixed
status-b2g-v2.1:
--- → fixed
Updated•10 years ago
|
Whiteboard: [systemsfe]
Target Milestone: --- → 2.0 S4 (20june)
You need to log in
before you can comment on or make changes to this bug.
Description
•