Closed Bug 834074 Opened 11 years ago Closed 11 years ago

third-party app self-update does not trigger update confirmation prompt

Categories

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

Product:
Firefox OS Graveyard
Component:
Gaia::System
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: myk, Unassigned)

Details

When my test external packaged app checks for and downloads an update from Marketplace, a notification icon appears in the status bar momentarily, but it goes away as quickly as it came, and my app is notified that its update was installed (i.e. its ondownloadapplied handler is called).

But as I understand it, when a packaged app uses the mozApps API to check for and download an update, the system should notify the user about the update and then wait to apply it until the user taps the notification and confirms it.

(And, per @sicking, an app should not get updated while it is still running; the system should wait until it quits--or it should force it to quit--before applying the update.)

I've only tested on B2G Desktop, but @\n saw the same behavior on a device.  Note that you need the fix for bug 833531 to observe this problem, since that bug prevents the packaged app update from working at all.

I'm testing with the PackStubTest app on this Gaia branch (for which you need to build with MAKECMDGOALS=dogfood, since the app only builds for dogfood profiles):

https://github.com/mykmelez/gaia/tree/packaged-app-stub

cc: @jcarpenter for his insight into the optimal system behavior during app self-updates.

cc: @sicking to confirm that the system shouldn't be updating an app while it's still running.

Requesting blocking-tef+, although I'm not sure this rises to the level of a blocker, since 1. the update does get applied (and arguably the UX is better for want of a prompt); and 2. the update appears to get applied correctly (even though the app is still running).  So the end result is a successful self-update, even if the flow is not what we intended nor what users expect.
I actually think this would block - we should not auto-apply updates utilizing resources without the user knowing what they are going download and know how much they are downloading. Downloading resources without a user's knowledge seems bad in that sense, as we are using network resources that cost money without the user's explicit control.
Mmm that's right, the app could |checkForUpdates|, and then |download| automatically. It would then be automagically applied.

A long-term solution would be to not let the app call |download|.

What would be the short-term solution ? The same ?
(In reply to Julien Wajsberg [:julienw] from comment #2)
> Mmm that's right, the app could |checkForUpdates|, and then |download|
> automatically. It would then be automagically applied.
> 

When the app goes in background right?
If we're applying with the app in the foreground that's a bug (and probably the bug).
(In reply to Jason Smith [:jsmith] from comment #1)
> utilizing resources without the user knowing what they are going download
> and know how much they are downloading.

Note that we have the network indicator, and any app can do that... (downloading stuffs)
(In reply to Etienne Segonzac (:etienne) from comment #3)

> If we're applying with the app in the foreground that's a bug (and probably
> the bug).

Yep, we're not doing that, I wasn't clear in my message, thanks :)

(In reply to Etienne Segonzac (:etienne) from comment #4)
> (In reply to Jason Smith [:jsmith] from comment #1)
> > utilizing resources without the user knowing what they are going download
> > and know how much they are downloading.
> 
> Note that we have the network indicator, and any app can do that...
> (downloading stuffs)

Discussing with Etienne, I now understand his position and I agree with that (I am so easily influenced).

Any app can do download already, and if an app want to auto-update itself, I don't see any problem with that. That's what happens with HTML5 appcache already so we won't be able to fix this in any situation anyway.

I suggest to close wontfix.
(In reply to Julien Wajsberg [:julienw] from comment #5)
> (In reply to Etienne Segonzac (:etienne) from comment #3)
> 
> > If we're applying with the app in the foreground that's a bug (and probably
> > the bug).
> 
> Yep, we're not doing that, I wasn't clear in my message, thanks :)
> 
> (In reply to Etienne Segonzac (:etienne) from comment #4)
> > (In reply to Jason Smith [:jsmith] from comment #1)
> > > utilizing resources without the user knowing what they are going download
> > > and know how much they are downloading.
> > 
> > Note that we have the network indicator, and any app can do that...
> > (downloading stuffs)
> 
> Discussing with Etienne, I now understand his position and I agree with that
> (I am so easily influenced).
> 
> Any app can do download already, and if an app want to auto-update itself, I
> don't see any problem with that. That's what happens with HTML5 appcache
> already so we won't be able to fix this in any situation anyway.
> 
> I suggest to close wontfix.

Going to pull this from triage until we get more information. I don't we're ready to wontfix just yet, however.

I think I need to hear both security and UX confirm this. In the past, there's been security requirements stating that the user always has to have control of the app they are installing - no web content can force an app onto the device. I wonder if the same rule applies here.

Paul - Are there any security risks with allowing an app to auto-apply updates without user control?

Josh - Should the user always have control of knowing when they can apply the update? Or should we allow an app to auto-update itself without user control.

Jonas - Do you have any thoughts on this?
blocking-b2g: tef? → ---
Flags: needinfo?(ptheriault)
Flags: needinfo?(jcarpenter)
Flags: needinfo?(jonas)
Summary: external packaged app self-update auto-applied → 3rd party apps can self-update themselves without going through the app update UI flow on device
(In reply to Jason Smith [:jsmith] from comment #6)

> I think I need to hear both security and UX confirm this. In the past,
> there's been security requirements stating that the user always has to have
> control of the app they are installing - no web content can force an app
> onto the device. I wonder if the same rule applies here.
> 

- this is not web content, only the installed app can't trigger an update.
- you don't force an app onto the device, it's already there.
(In reply to Julien Wajsberg [:julienw] from comment #7)
> (In reply to Jason Smith [:jsmith] from comment #6)
> 
> > I think I need to hear both security and UX confirm this. In the past,
> > there's been security requirements stating that the user always has to have
> > control of the app they are installing - no web content can force an app
> > onto the device. I wonder if the same rule applies here.
> > 
> 
> - this is not web content, only the installed app can't trigger an update.
> - you don't force an app onto the device, it's already there.

Well in this case, it's the content of the app that can force the update to itself without user control.
Yep, that's it, I wanted to make it clear for the external consultants ;-)
(In reply to Jason Smith [:jsmith] from comment #1)
> I actually think this would block - we should not auto-apply updates
> utilizing resources without the user knowing what they are going download
> and know how much they are downloading.

This bug is not about the download, it's about what happens after the download is complete.


(In reply to Julien Wajsberg [:julienw] from comment #5)
> (In reply to Etienne Segonzac (:etienne) from comment #3)
> 
> > If we're applying with the app in the foreground that's a bug (and probably
> > the bug).
> 
> Yep, we're not doing that, I wasn't clear in my message, thanks :)

I did some more testing, and it looks like the system does wait for my test app to quit before applying the update, but I noticed a race between the app's window.close() call and the downloadapplied event: after calling window.close(), the app observes downloadapplied right before it quits.  So we may be applying the download a bit early (or unloading the app a bit late).


But the primary issue in this bug is not when the update is applied but that it is applied without prompting the user to confirm the update.

Perhaps that's actually desired behavior, and we should wontfix the bug (which couldn't make me happier, since I'm no fan of these prompts).

But my understanding is that the system is supposed to prompt the user to apply all updates, regardless of who triggered the update check and download (the periodic system check, a manual user check, or an ad-hoc app self-check).

And if it turns out that we don't want the prompt when an app self-updates, then there's still the problem that some notification appears momentarily during the update process (although that's a much less significant problem).
@jsmith: I'm updating the title to clarify that the problem here is not that apps can update themselves (which is a feature of the mozApps API, not a bug) but that such updates bypass the system's app update confirmation prompt.

(I'm also making it shorter, so it fits better into all sorts of interfaces that display bug titles. ;-) )
Summary: 3rd party apps can self-update themselves without going through the app update UI flow on device → third-party app self-update does not trigger update confirmation prompt
Yep, I've noticed that the app gets the downloadapplied event too. Is this really an issue ? Even if it displays something the user won't see it anyway.

We're listening for the "appwillclose" event, maybe another event (I believe we have "appclose" too) may be more suited but this is another bug anyway.
(In reply to Julien Wajsberg [:julienw] from comment #12)
> Yep, I've noticed that the app gets the downloadapplied event too. Is this
> really an issue ? Even if it displays something the user won't see it anyway.

My test app displays something on downloadapplied, and I do see it flash onto the screen right before the app disappears, so the race does have some effect.  Nevertheless, it seems like a minor issue.


> We're listening for the "appwillclose" event, maybe another event (I believe
> we have "appclose" too) may be more suited but this is another bug anyway.

Right, I have filed bug 834292 on it.  Let's keep this bug focused on the issue that the system does not prompt the user to confirm the update.
An app should definitely be able to both do checkForUpdate on itself as well as trigger the download a found update. That is entirely by design. Otherwise apps will just work around the limitation by dynamically downloading code and storing it in local storage.


We also have never had a prompt for applying an update.

What we do have is a prompt before using bandwidth to download an update. But apps can always use bandwidth for any purpose without prompting. We trust them to do so responsibly. So there is no point in forbidding them from starting a download.

What we hopefully will have in a future release is the ability to track data usage per-app. At which point an app-triggered update should count towards the app.

It is in fact quite important for many app developers that they can keep the app up-to-date on the device for security reasons. Just look at how much effort Firefox Desktop is spending on that. WebApps are no different in this regard.


The only bug here seems to be that we trigger applying the update a little too early. The app should never be able to see itself getting updated. Not even during its own shutdown. Likely that can cause weird behavior if the app starts a load during shutdown.

But I don't think that's a blocker. And it's unclear if that's a gaia or gecko bug.
Flags: needinfo?(jonas)
Per Jona's ocmment WONTFIXing here, and taking the race to bug 834292.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Flags: needinfo?(ptheriault)
Flags: needinfo?(jcarpenter)
What would should have is a display of the the size of the package so the user understands how much of their data quota the update will consume, which I think is a different than a user's understanding that the app will use data for its intended purpose.  Don't know if this is possible.
(In reply to David Bialer [:dbialer] from comment #16)
> What would should have is a display of the the size of the package so the
> user understands how much of their data quota the update will consume, which
> I think is a different than a user's understanding that the app will use
> data for its intended purpose.  Don't know if this is possible.

We would know the downloadSize after checking for update, so we can delay the install.  But a network request to check for update is necessary first.
(In reply to Nick Desaulniers [:\n] from comment #17)
> (In reply to David Bialer [:dbialer] from comment #16)
> > What would should have is a display of the the size of the package so the
> > user understands how much of their data quota the update will consume, which
> > I think is a different than a user's understanding that the app will use
> > data for its intended purpose.  Don't know if this is possible.
> 
> We would know the downloadSize after checking for update, so we can delay
> the install.  But a network request to check for update is necessary first.

Sounds like that might be a worthwhile feature request then for the stub.
We know the downloadSize only if the developer specified this in the manifest. Also it might be wrong.

However, in the update notification, we display the downloaded bytes so far.
Perhaps this should be a required field for packaged app manifests, at least to Firefox Marketplace, which we could validate on app submission/update.  Otherwise, if it isn't set, it could say that the update size is unknown. 

Flow
User press button to check for update
Stub Checks for manifest change, if found checks for size in manifest.
User sees Update Found, Size X MB.  Download Now? (yes/no) or Update Found, Size Unknown.  Download Now?(y/n).
....
(In reply to David Bialer [:dbialer] from comment #20)
> Perhaps this should be a required field for packaged app manifests, at least
> to Firefox Marketplace, which we could validate on app submission/update. 
> Otherwise, if it isn't set, it could say that the update size is unknown. 
> 
> Flow
> User press button to check for update
> Stub Checks for manifest change, if found checks for size in manifest.
> User sees Update Found, Size X MB.  Download Now? (yes/no) or Update Found,
> Size Unknown.  Download Now?(y/n).
> ....

Marketplace I believe actually already sets the size for each packaged app zip that's submitted. So this issue wouldn't impact marketplace.
(In reply to Julien Wajsberg [:julienw] from comment #19)
> We know the downloadSize only if the developer specified this in the
> manifest. Also it might be wrong.
> 
> However, in the update notification, we display the downloaded bytes so far.

The marketplace sets the size field of the mini manifest when the zip is uploaded.  But not all packaged apps need to go through our marketplace (right?).  As far as app stubs are concerned, I believe all future versions will be hosted at the marketplace.
(In reply to Nick Desaulniers [:\n] from comment #22)
> The marketplace sets the size field of the mini manifest when the zip is
> uploaded.  But not all packaged apps need to go through our marketplace
> (right?).  As far as app stubs are concerned, I believe all future versions
> will be hosted at the marketplace.

In v1, all packaged apps need to go through our marketplace, and all stub updates will be hosted there, so the stub UI does not need to account for the possibility that the minimanifest doesn't specify a package size.
Well, I'm not sure when you want to display this ? I don't get it.
(In reply to Myk Melez [:myk] [@mykmelez] from comment #23)

> In v1, all packaged apps need to go through our marketplace, and all stub
> updates will be hosted there, so the stub UI does not need to account for
> the possibility that the minimanifest doesn't specify a package size.

All the *signed* packaged apps need to go through our marketplace. Non-signed can be served from anywhere.
(In reply to Julien Wajsberg [:julienw] from comment #24)
> Well, I'm not sure when you want to display this ? I don't get it.

@\n and @dbialer are discussing information to display in the interface of the stub app itself, not in Gaia.


(In reply to Fabrice Desré [:fabrice] from comment #25)
> (In reply to Myk Melez [:myk] [@mykmelez] from comment #23)
> 
> > In v1, all packaged apps need to go through our marketplace, and all stub
> > updates will be hosted there, so the stub UI does not need to account for
> > the possibility that the minimanifest doesn't specify a package size.
> 
> All the *signed* packaged apps need to go through our marketplace.
> Non-signed can be served from anywhere.

Ah, thanks for the correction!


In any case, we're now discussing the interface of the stub app, which is outside of the scope of this bug, so let's take that discussion elsewhere!
No longer blocks: b2g-app-updates, 804049
You need to log in before you can comment on or make changes to this bug.