744715 - Automatically check for updates for "pinned" apps ever X hours

Status: RESOLVED WONTFIX

(Core :: Networking: Cache, defect, P2)

Description

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

By pinning an app the user has indicated that they are going to use the app a lot. We should automatically check such an app for updates every so often so that when the user goes to use the app, the latest version is always available.

That way users aren't always faced with "there's an update for this app available" dialogs whenever an pinned app is opened for the first time in a while. Instead they immediately get the latest version.

Comment 1

[Johnny Stenback (:jst)]

Over to Ben who will be working on app cache related stuff very shortly.

Comment 2

[Johnny Stenback (:jst)]

This blocks our webapps story, so blocking kilimanjaro.

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I am not sure end-users will want us polling the website of each app that they downloaded over and over again. It would be horrible for battery life. Generally, app updates are just a type of notification and IMO we should use mechanisms the same/similar to the notification mechanisms we have planned in B2G and non-B2G Gecko. That is, you should receive a push notification to your phone when an app is updated. 

Polling the websites also has tracking/privacy concerns because implementing this would mean that anybody that can convince you to install their app can track your location (e.g. through geo-IP) indefinitely, even if you never use the app after you install it. This would likely make this mutually-exclusive with bug 715789, because I don't think we can silently opt the user into long-term (permanenet) location tracking by any website they visit.

Comment 5

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Agreed, the medium-term plan is for server push.  This is a fallback strategy.

To be clear, the main use case here is for polling "trusted" store servers for updates to explicitly-installed apps.

Comment 6

[Eric Shepherd [:sheppy]]

Marking dev-doc-needed mostly because web app devs will want to be able to note this in their user docs.

Comment 7

[Thinker Li [:sinker]]

Is there any one working on this bug?

Comment 8

[[:fabrice] Fabrice Desré]

Is this bug about updating the offline-cache for apps that have one?

If yes, since we added support to fire events on mozApps objects when we preload the offline cache during install, we should also support these events when updating.

Comment 9

[Thinker Li [:sinker]]

(In reply to Fabrice Desré [:fabrice] from comment #8)
> Is this bug about updating the offline-cache for apps that have one?
> 
> If yes, since we added support to fire events on mozApps objects when we
> preload the offline cache during install, we should also support these
> events when updating.

Do you mean to fire an event on mozApps once an App been updated?

Comment 10

[[:fabrice] Fabrice Desré]

(In reply to Thinker Li [:sinker] from comment #9)

> Do you mean to fire an event on mozApps once an App been updated?

We fire install progress events on the App itself while we are downloading its appcache.

Comment 11

[Thinker Li [:sinker]]

I think the checking and downloading is running at background automatically.  Should we show the progress bar to user?

Comment 12

[[:fabrice] Fabrice Desré]

(In reply to Thinker Li [:sinker] from comment #11)
> I think the checking and downloading is running at background automatically.

It happens when we open a page referring to an offline cache manifest. We're not tracking these yet to send apps events. Also, this is not a good user experience since the app has to be closed and reopened to use the new cache.

> Should we show the progress bar to user?

That's up to the UI layer, but we should give it the opportunity to do so.

Comment 13

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: the first version of nsIApplicationCacheUpdateService.idl

I've drawed up the first version of nsIApplicationCacheUpdateService.idl, and it has been attached. Please let me know if you have any comment or thoughts. Thanks.

Comment 14

[Thinker Li [:sinker]]

This bug would interact with several parts of the rest.  For example, it should be enabled if a network connection was established and be down if all connections are down.  It also need a list of applications since not every cache in the offlinecache device is also an installed applications. And there are several other scenarios that effect this bug.  After talking with Gina, I suggest to keep this bug simple, be a component accepts the list from others and being enabled/disable by others.  Gina will file follow up bugs to connect everything together.

Comment 15

[[:fabrice] Fabrice Desré]

I think this would be simpler to do at a the Webapps.jsm level, where we have all the information needed about which app uses an offline cache.

Comment 16

[Kai-Chih Hu [:khu]]

(In reply to Thinker Li [:sinker] from comment #14)
> This bug would interact with several parts of the rest.  For example, it
> should be enabled if a network connection was established and be down if all
> connections are down.  It also need a list of applications since not every

So, we need to detect WiFi connections 'and' 3G connections, right? 
If either one is enabled and connection is established, this feature will be enabled. 

> cache in the offlinecache device is also an installed applications. And
> there are several other scenarios that effect this bug.  After talking with
> Gina, I suggest to keep this bug simple, be a component accepts the list
> from others and being enabled/disable by others.  Gina will file follow up
> bugs to connect everything together.

Comment 17

[Kai-Chih Hu [:khu]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #5)
> Agreed, the medium-term plan is for server push.  This is a fallback
> strategy.
> 
> To be clear, the main use case here is for polling "trusted" store servers
> for updates to explicitly-installed apps.

May I know how could we identify trusted store servers? 
Thanks.

Comment 18

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: nsIApplicationCacheUpdateService.idl V2

Add one attribute to record update frequency. The time unit is hour.

Comment 19

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: ApplicationCacheUpdateService.js V1

implementation of nsIApplicationCacheUpdateService.idl

Comment 20

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: ApplicationCacheUpdateService.manifest V1

Comment 21

[Gina Yeh [:gyeh] [:ginayeh]]

Attachment: test_appcache.js V1

an unit test for ApplicationCacheUpdateService.js

In the test, firstly, a few entries are added. Secondly, remove one entry from the list. Thirdly, enable update service. Fourthly, disable update service.

Comment 22

[[:fabrice] Fabrice Desré]

Gina, I posted my wip patch for packaged apps updates in bug 772364. I put a comment where the offline cache updates should be plugged in.

Comment 23

[Andreas Gal :gal]

How are we doing here?

Comment 24

[Andreas Gal :gal]

Renom if you think we can't ship a v1 without this.

Comment 25

[Jason Smith [:jsmith]]

Per IRC conversations with a few other folks, I think the best course of action if there is disagreement on whether this blocks or not is to do the following:

- Move the blocking-basecamp flag to ? for re-evaluation
- Indicate a rationale for why you disagree

Comment 26

[Andrew Overholt [:overholt]]

Where are we on updates from a UX perspective, Josh?

Comment 27

[Josh Carpenter [:jcarpenter]]

This is the first I've heard of this bug. Will roll it into our current Updates work and get back to this thread with response.

Comment 28

[Josh Carpenter [:jcarpenter]]

This is related to:

* App Update specs: https://www.dropbox.com/sh/23ri1b7tfr03qd4/tSbqoawnPT
* App Install specs: https://www.dropbox.com/sh/b0kyykhzcfkpm8b/ReFTX_E72X
* Bug 751754: https://bugzilla.mozilla.org/show_bug.cgi?id=751754
* Bug 740722: https://bugzilla.mozilla.org/show_bug.cgi?id=740722

The Update specs above also use an automatic timed update mechanism, but it's envisioned as having some nuances:

• By default, scheduled automatic update checks are restricted to WiFi or zero-rated connections only.

• If there is no active WiFi or zero- rated connection at the scheduled check time, the check fails silently.

• When the connection type changes to WiFi or zero-rated, the system checks to see if any scheduled checks were missed. If true, the system checks for an update immediately, instead of waiting until the next scheduled time.

• User can set the frequency of scheduled update checks from the Settings within the App Update and System Update utilities.

Comment 29

[Andrew Overholt [:overholt]]

This doesn't appear to be in the v1 update UX design.

Comment 30

[Josh Carpenter [:jcarpenter]]

Au contraire. As per Comment 28, automatically checking for updates (both for System and Apps) at a timed interval is essential to the proposed updates UX spec: https://www.dropbox.com/sh/23ri1b7tfr03qd4/tSbqoawnPT

This should be blocking-basecamp + unless we want to switch to manual updates only for v1.

Comment 31

[[:fabrice] Fabrice Desré]

(In reply to Josh Carpenter [:jcarpenter] from comment #30)
> Au contraire. As per Comment 28, automatically checking for updates (both
> for System and Apps) at a timed interval is essential to the proposed
> updates UX spec: https://www.dropbox.com/sh/23ri1b7tfr03qd4/tSbqoawnPT
> 
> This should be blocking-basecamp + unless we want to switch to manual
> updates only for v1.

Josh, the title of this bug is misleading. It only deals with updating the offline-cache.

Comment 32

[Andrew Overholt [:overholt]]

Fabrice confirmed this case shouldn't block v1.

Comment 33

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

If the marketplace app is still going to use appcache, we might need to reevaluate that.

Comment 34

[Jason Smith [:jsmith]]

(In reply to Chris Jones [:cjones] [:warhammer] from comment #33)
> If the marketplace app is still going to use appcache, we might need to
> reevaluate that.

Marketplace is planning to use appcache actually, and it's a v1 requirement that offline mode work with marketplace. Renoming.

Comment 35

[[:fabrice] Fabrice Desré]

We'll have appcache updates, but definitely not using the approach from this bug. Stop renoming that please.

Comment 36

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yes, the approach described in this bug is to have gecko automatically check for updates on a set schedule. The approach we should be using is instead to expose API to Gaia so that Gaia can check for updates using more advanced policies affected by UI, settings, current connectivity etc.

Bug 790558 is the tracker for adding such API.

Comment 37

[Chris Jones [:cjones] inactive; ni?/f?/r? if you need me]

Should we just WONTFIX this in favor of bug 790558 then?

That bug will need to block if it's a product requirement for the marketplace to ever update.

Comment 38

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Yup