816128 - [system] Do the Right Thing when the user tries to cancel the installation of an hosted app

Status: RESOLVED DUPLICATE of bug 819974

(Firefox OS Graveyard :: Gaia::System, defect, P2)

Description

[Julien Wajsberg [:julienw]]

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).

Comment 1

[Chris Lee [:clee]]

Is the user impact that if they cancel a hosted app install, I'm assuming the app will still install?

Comment 2

[Julien Wajsberg [:julienw]]

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

[Dylan Oliver [:doliver]]

blocking+

Not sure on the correct solution but need to clean up the experience.

Comment 4

[Josh Carpenter [:jcarpenter]]

(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.

Comment 5

[[:fabrice] Fabrice Desré]

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.

Comment 6

[Honza Bambas (:mayhemer)]

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.

Comment 7

[Honza Bambas (:mayhemer)]

(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

[[:fabrice] Fabrice Desré]

Honza, great info, thanks!

Comment 9

[Julien Wajsberg [:julienw]]

Fabrice, will you work on platform support for canceling hosted-app-with-appcache ?

Comment 10

[[:fabrice] Fabrice Desré]

(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...

Comment 11

[Julien Wajsberg [:julienw]]

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

[Alex Keybl [:akeybl]]

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.

Comment 13

[Dietrich Ayala (:dietrich)]

Julien, Fabrice - what needs to happen here?

Comment 14

[[:fabrice] Fabrice Desré]

Hm, isn't it a dupe of Bug 819974 ?

Comment 15

[Jason Smith [:jsmith]]

(In reply to Fabrice Desré [:fabrice] from comment #14)
> Hm, isn't it a dupe of Bug 819974 ?

Sounds like a dupe to me.

Comment 16

[Jason Smith [:jsmith]]

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.

Comment 17

[Julien Wajsberg [:julienw]]

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

[Dietrich Ayala (:dietrich)]

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.