Asking why your offline application cache manifest doesn't work in Firefox and have no way to figure out?  Not any more.  Now you can look in to the Error Console (the old fashion one) you open with Shift-Ctrl-J and check for logs I've recently added in bug 807501.  All these logs are under the Messages section.  When an update is internally invoked, there is always at least one message related to the processed cache manifest.

When an error during cache update occurs you can now see the reason:

When all goes well, i.e. Firefox has downloaded or updated your offline cache, you get:

• Offline cache update done, URL=http://example.com/cache.manifest

And when you are sure you've changed your manifest to a new version, but offline cache doesn't update in Firefox, you can check for the following line:

• Offline cache doesn't need to update, URL=http://example.com/cache.manifest

This means the manifest hasn't changed since the last time or that you didn't serve it with Cache-control: no-cache header.

As the maintainer, I was asked to summarize issues with famous Offline Application Cache, so here it is.

Current status of how application cache is implemented in Firefox isn't perfect.  From both the user's point of view as well as developer's point of view.  Except web content, that didn't adopt this technology very widely, there are new consumers: Boot2Gecko and Open Web Apps support.  Time to return and improve.

The most important issues that may imply a spec update:

The prompt.

Most people (both users and developers) hate the prompt that pops up and needs to be accepted when a page or an app (I'll use the word "app" in the following text) wants to cache it self.  This is not that simple to remove because:

- If we accept automatically, we open potential for DoS attack on user's storage.  The limits for offline content are wider and there is a poor way of automatic eviction of offline cache from one's disk if we want to behave by the spec.

- Accepting allows persistent cookies.  In my opinion, more of a problem.

Deleting the cache is hard.

Until you visit the app's main page again, the cache has no chance to get off of your disk.  It can of course be deleted by Clear Recent History command (Shift-Ctrl-Del) and also somewhere deep in the Options dialog, but who does it?  So the cache may easily just waste disk capacity.

The space on user's disk dedicated to offline apps is large, so apps can pile.  We'd like to lower the space limit down, mainly on mobile.  It means to throw long time unused offline apps silently away sometimes.

Recently there had been introduced app "pinning".  "Pinned" apps are not removed automatically and have a separate (larger) disk space.  That sounds opposite, right?  But this opens space to turn common (unpinned) web apps to an intermediate layer.  To explain:

- Layer 1 - Web content HTTP cache (this is not offline app cache):  makes your browsing faster.  Quickly flows, old content is silently threw away, replaced with more recent and current.   The most recent news articles are cached here along with CSS of the page.

- Layer 2 - Offline application cache:  intended to cache only the "code", simpler said, persists "the machine", not the data flowing through it.  Design flaws prevent use of this level to improve caching to be more effective on usual web sites dayly used.  I believe the "make this available when browser is offline" bit haven't hit the target well.  This level should just behave closer to how HTTP cache works - i.e. automatically.

- Layer 3 - Pinned applications cache:  actually what the current spec for offline application cache is about, but even more persistent.  It can, because it will have a full user's consent - a prompt or some other obvious UX path such as an OWA installation.  This will be used for critical applications that need to be available also offline.

To sum: change the default offline application cache behavior to be more like a "flow" then a "room for old boxes".

(Not only) user's data saved by apps.

DOM storage (window.localStorage) and IndexedDB content written by an offline app is not deleted along with cookies when history is deleted.  The storage used by an app is understood as a storage for user's critical data, like documents, email concepts, calendar entries, whatever, stored locally.  That obviously cannot be deleted just by removing cookies.

This could however, when not accepted explicitly, be misused by a malicious site to store a very persistent cookies.  Users delete their cookies to get rid of tracking or to log out, not to delete their work.  If you want to delete any of these "very persistent" cookies, you have to delete all the app cached content and also your potentially critical data.

We may either remove support for such user data (I vote against!) or, do something of this:

- Split the 'allow offline caching' and 'allow user's documents' privileges.  Simply: when an app defines a manifest, cache it automatically, no prompt.  When that app wants to use some data persistent storage to e.g. save your document concept, prompt to get user's consent.  This doesn't allow tracking more then today, but I assume the prompt will appear in 90% of cases anyway.  At least localStorage is widely used.

- Expose a new web content API that an app may use to ask for e.g. a new IndexedDB or localStorage instance to write and read critical data like documents that must not be deleted w/o user's knowledge, or at least that simply as e.g. cookies.  User may be prompted to let the app use this API.  It may be similar to a selection of a file.  Also we can bind to user's identity managed by the browser.  New open area to design.

(Not) being up to date.

Offline cache content of an app now updates only after you visit the app's main page.  Only then we check whether the manifest of the cache has changed on the server.  If so, we download a new version.  The whole page then has to refresh to use the newer version.

This behavior is by the spec.  And has usability and also security implications since on the visit user may see and use the old content.  It updates on next visit only or after an explicit refresh.  So, you may always be one version late.

We want to change this to periodically check the manifest on the server.  This will ensure that on next visit you won't be bothered with reload and also will be using up to date content with all security issue fixed and so.