Closed Bug 816128 Opened 7 years ago Closed 7 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)

Other
Gonk (Firefox OS)
defect

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).
blocking-basecamp: --- → ?
Flags: needinfo?(jcarpenter)
OS: Linux → Gonk (Firefox OS)
Hardware: x86_64 → Other
Is the user impact that if they cancel a hosted app install, I'm assuming the app will still install?
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.
blocking+

Not sure on the correct solution but need to clean up the experience.
blocking-basecamp: ? → +
Priority: -- → P2
(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)
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)
Assignee: nobody → felash
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)
(In reply to Honza Bambas (:mayhemer) from comment #6)
> There is already a working Cancel() method, but it is *NOT* exposed in the 
> interface.
Honza, great info, thanks!
Fabrice, will you work on platform support for canceling hosted-app-with-appcache ?
(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...
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 ?
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)
Julien, Fabrice - what needs to happen here?
Hm, isn't it a dupe of Bug 819974 ?
(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: 7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 819974
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 → ---
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.
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: 7 years ago7 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 819974
You need to log in before you can comment on or make changes to this bug.