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.

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

This blocks our webapps story, so blocking kilimanjaro.

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.

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.

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

Is there any one working on this bug?

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.

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

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

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

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

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.

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.

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.

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

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

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

implementation of nsIApplicationCacheUpdateService.idl

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.

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.

How are we doing here?

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

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

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

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.

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.

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

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.

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

Fabrice confirmed this case shouldn't block v1.

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

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

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

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.

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.

Yup