Closed
Bug 816128
Opened 12 years ago
Closed 12 years ago
[system] Do the Right Thing when the user tries to cancel the installation of an hosted app
Categories
(Firefox OS Graveyard :: Gaia::System, defect, P2)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 819974
B2G C3 (12dec-1jan)
People
(Reporter: julienw, Assigned: julienw)
References
Details
Bug 802600 added the cancel install feature.
However, the platform doesn't support cancelling an install if this is an hosted application (with app cache) yet.
This bug is about doing the Right Thing in this case.
(The Right Thing is to be defined).
Assignee | ||
Updated•12 years ago
|
blocking-basecamp: --- → ?
Flags: needinfo?(jcarpenter)
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → Other
Comment 1•12 years ago
|
||
Is the user impact that if they cancel a hosted app install, I'm assuming the app will still install?
Assignee | ||
Comment 2•12 years ago
|
||
Yes it is.
Actually, what we get now is :
- the user gets the notification in the notification center
- he can tap it to trigger a cancel
- he gets a confirmation dialog
- he taps "Confirm" to actually cancel the download
- the dialog vanishes and nothing happens (ie: the notification is still there, and the download is still happening)
Under the hood, the system app calls cancelDownload on the app object, and cancelDownload silently returns doing nothing if this is an hosted app.
Fabrice proposed to not show the download install notification in case of hosted app with appcache because the user can do no action with it. However we could keep the icon.
Comment 3•12 years ago
|
||
blocking+
Not sure on the correct solution but need to clean up the experience.
blocking-basecamp: ? → +
Priority: -- → P2
Comment 4•12 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #0)
> Bug 802600 added the cancel install feature.
>
> However, the platform doesn't support cancelling an install if this is an
> hosted application (with app cache) yet.
How hard would it be to add the platform support? The spec defined the "Cancel" flow as being identical for both Hosted-with-app-cache and Packaged apps:
https://www.dropbox.com/sh/b0kyykhzcfkpm8b/ReFTX_E72X
(page 10)
> Fabrice proposed to not show the download install notification in case of
> hosted app with appcache because the user can do no action with it. However
> we could keep the icon.
If adding the necessary platform support is not feasible for v1, then this sounds like a reasonable fall-back.
Flags: needinfo?(jcarpenter)
Comment 5•12 years ago
|
||
We'll have support to check for appcache updates (see bug 809947), but not yet to cancel them. Pinging Honza to know hard this would be.
Flags: needinfo?(honzab.moz)
Updated•12 years ago
|
Assignee: nobody → felash
Comment 6•12 years ago
|
||
If you don't have the running update in your possession, you have nsIOfflineCacheUpdateService ("@mozilla.org/offlinecacheupdate-service;1") with numUpdates and getUpdate(index) methods. Just find your update by checking nsIOfflineCacheUpdate.manifestURI on all updates you get from getUpdate() calls. We need to patch nsIOfflineCacheUpdate and nsOfflineCacheUpdate. There is already a working Cancel() method, but it is on exposed in the interface. It needs to be done. Then when you have it, just use that method to cancel the update. Other way is to introduce some cancelUpdate(manifestURL) method to nsIOfflineCacheUpdateService, it might be simpler to use.
Flags: needinfo?(honzab.moz)
Comment 7•12 years ago
|
||
(In reply to Honza Bambas (:mayhemer) from comment #6)
> There is already a working Cancel() method, but it is *NOT* exposed in the
> interface.
Comment 8•12 years ago
|
||
Honza, great info, thanks!
Assignee | ||
Comment 9•12 years ago
|
||
Fabrice, will you work on platform support for canceling hosted-app-with-appcache ?
Comment 10•12 years ago
|
||
(In reply to Julien Wajsberg [:julienw] from comment #9)
> Fabrice, will you work on platform support for canceling
> hosted-app-with-appcache ?
I can, but not this week for sure...
Assignee | ||
Comment 11•12 years ago
|
||
This is not planned for the C2 milestone so we can wait ;)
If this will eventually be implemented in the platform, then I think there is no work to do in gaia, and you should take this bug. Do you agree ?
Comment 12•12 years ago
|
||
Mass Modify: All un-milestoned, unresolved blocking-basecamp+ bugs are being moved into the C3 milestone. Note that the target milestone does not mean that these bugs can't be resolved prior to 12/10, rather C2 bugs should be prioritized ahead of C3 bugs.
Target Milestone: --- → B2G C3 (12dec-1jan)
Comment 13•12 years ago
|
||
Julien, Fabrice - what needs to happen here?
Comment 14•12 years ago
|
||
Hm, isn't it a dupe of Bug 819974 ?
Comment 15•12 years ago
|
||
(In reply to Fabrice Desré [:fabrice] from comment #14)
> Hm, isn't it a dupe of Bug 819974 ?
Sounds like a dupe to me.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → DUPLICATE
Comment 16•12 years ago
|
||
Oh wait, now I understand what this is. It's the gaia equilvalent of the platform work in bug 819974 if there is any. If there isn't any, then we can get rid of this bug.
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Assignee | ||
Comment 17•12 years ago
|
||
I think there will be no gaia work on this, as the API is the same for packaged app and hosted apps.
I suggest we keep this one opened until bug 819974 is fixed and check if anything works correctly in gaia.
Comment 18•12 years ago
|
||
Driver retriage. All the code and all the fix is happening in bug 819974, so re-duping this against it.
Adding a note in the other bug for QA to check steps here when verifying.
Status: REOPENED → RESOLVED
blocking-basecamp: + → ---
Closed: 12 years ago → 12 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•