New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 28 users

Issue metadata

Status: Assigned
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Sign in to add a comment

appcache is being created and updated even though service worker causes it to be bypassed

Project Member Reported by, Sep 4 2014

Issue description

Based on

"If the navigation is under the scope of a SW, appcache is completely bypassed, regardless of whether the navigation uses the SW.

If a SW is installed and covers the reach of a manifest, the UA may garbage collect all the appcache stuff.

This allows devs to use appcache as a fallback (if it's suitable) for browsers that don't support SW, then use SW to do offline++."

Michael, Matt, did I see a patch being reviewed related to Service Worker, AppCache interation?
Michael's patch is at -- it seems it still needs more work.
Status: Started
Sounds like it is in progress.
Project Member

Comment 4 by, Oct 21 2014

The following revision refers to this bug:

commit 22390646e70aba2bb8e90688f9a6351f9571bca3
Author: michaeln <>
Date: Tue Oct 21 03:07:43 2014

Pages controlled by ServiceWorkers should not participate in AppCaching. The manifest attribute of pages in the scope of a ServiceWorker are ignored, and existing AppCaches are ignored for navigations into a ServiceWorker's scope.


Review URL:

Cr-Commit-Position: refs/heads/master@{#300406}


> "If the navigation is under the scope of a SW, appcache is completely
> bypassed, regardless of whether the navigation uses the SW.

^^^ That much is done.

> If a SW is installed and covers the reach of a manifest,
> the UA may garbage collect all the appcache stuff.

^^^ And this part is not yet done.
Michael, would you consider adding a warning in the console explaining what is happening and why? (per feedback from DevRel hackathon).

Comment 8 by, Oct 24 2014

Yes, sounds like a nice to have feature.

Comment 9 by, Nov 10 2014

Labels: M-41
Labels: -M-41 M-42
Labels: -M-42 M-43 MovedFrom-42
[AUTO] Moving all non essential bugs to the next Milestone.  (This decision is based on the labels attached to your ticket.)

Owner: ----
Status: Available
Michael, let us know if you intended to finish this one.

Reverting to available in the meantime.
The Developer facing explanation would be great to have.
It seems that AppCache is not completely bypassed. Sakamoto-san might have a repro.
Here's what I saw today:

1. Visit
2. Go to chrome://serviceworker-internals/, see that a SW for is installed.
3. From chrome://appcache-internals/, remove the appcache entry for
4. Reload the tab opened in 1.
5. Although the page is now controlled by SW, the appcache entry is re-created.

Ooops, I think i see whats going on? AppCacheHost enable_cache_selection() is not being called in this case, so the manifest attribute is being processed when it shouldn't be.

The requests are being routed to the SW's as they should be without using any resources in the appcache (which is good) but the appcache is being created and updated when it shouldn't be (which is bad).

Labels: -M-43 MovedFrom-43
Status: Assigned
[AUTO] This issue has already been moved once and is lower than Priority 1,therefore removing mstone.
Labels: M-47

Comment 18 Deleted

Labels: Hotlist-Recharge
This issue likely requires triage.  The current issue owner may be inactive (i.e. hasn't fixed an issue in the last 30 days or commented in this particular issue in the last 90 days).  Thanks for helping out!

Labels: -M-47 M-49
Summary: appcache is being created and updated even service worker causes it to be bypassed (was: ServiceWorker wins over appcache)
Retitling bug.

Comment 21 by, May 4 2016

In Chrome 50.0.2661.94, still seeing window.applicationCache update events with service worker in place and caching. Also on window.applicationCache update, window.applicationCache.swapCache() throws an error.

Easy workaround is to not add update listener to window.applicationCache if serviceWorker in navigator but not ideal.

Comment 22 by, May 31 2016

The bug is still present in v51.x

When both AppCache and ServiceWorker are enabled:
1) The AppCache files remain in browser storage (and they occupy site quota) 
2) In every site access, the AppCache manifest is checked for updates and if such is found, every file specified for caching is downloaded again and the local cache is updated.

I believe none of these should happen according to the specs.
IMHO this bug should have much higher priority, as it ruins the ServiceWorker experience/migration.
It prevent us to enable ServiceWorker for Chrome/Chromium, because it leads to double cache download size & time (we need to keep providing AppCache manifest for non-ServiceWorker-browsers).
yup, i'll take a look

Comment 24 by, Sep 14 2016

Note this issue affects the latest release of Construct 2 (, which uses SW for offline support with fallback to AppCache for other browsers.
Labels: -M-49 M-57
Status: Started (was: Assigned)
Summary: appcache is being created and updated even though service worker causes it to be bypassed (was: appcache is being created and updated even service worker causes it to be bypassed)
I'm going to give this a try.
Can someone give very detailed repro steps? I can't repro even on Chrome 51 contrary to comments on this bug.

Here's what I did:
- Create a site that uses appcache
- Verify appcache updateready, cached events are fired.
- Register a service worker and wait for it to be ready
- Reload the page
- Verify the page is controlled by the service worker
- Verify that no appcache checking, updateready, noupdate, etc. events were fired.
- Try changing the manifest and reload.
- Verify the same again.

Here's my site:

Comment 27 by, Dec 16 2016

Your appcache manifest is not correct. It should include index.html (so that the site can work offline)

Here's mine:
# v1 - 2016-12-13
# This is a comment.
# This is another comment



If you use that, you'll see that on every reload an "appcache noupdate event" is triggered.
And if you have DevTools open and do a hard reload an appcache checking event is triggered.

Apart from that, the AppCache storage still contains data after SW is registered and it occupies site quota. 
Firefox gets it right and completely discards AppCache data and bypasses any AppCache interaction.

Comment 28 by, Dec 16 2016

Also the ServiceWorker script should cache the same files that AppCache manifest caches (including index.html). At least this is how it's used in our production environment.

Thanks ps@! Unfortunately I still can't repro. I updated the site: <http://localhost:9899/sw/test/sw-and-appcache/example.appcache> and did the following.

1) Clear service worker and appcache and navigate to Output:
appcache checking event
appcache downloading event
appcache cached event

2) Reload. Output:
appcache checking event
appcache noupdate event

3) Click "Register". Reload. Output:
controlled by service worker

What am I missing?

I do see that hard reload will trigger the AppCache, but not soft reload.

Also to help understand priority, would a workaround be to only set the appcache manifest if the UA agent string indicates SW is unsupported?

Ah sorry, not localhost:9899 of course.

Comment 31 by, Dec 19 2016

Thanks for your effort for solving this!
I'll come back soon with an example that demonstrates the problem
Hi ps@ can you (or anyone) help with a repro? I am considering closing this bug and having someone reopen once a repro exists.

I'd like to move the garbage collection of appcache to a different bug. This bug is specifically about not creating/updating appcache when the page is controlled by a SW.

Comment 33 Deleted

Comment 34 by, Jan 13 2017

Hi falken@, can you give the weekend to work on a repro?
kylebarrow@: Sure, that'd be super appreciated.

Comment 36 by, Jan 14 2017

Hi falken@, sorry for the delay on this. Here's how to reproduce it:

- Create a serviceworker that caches the same files as AppCache and most importantly index.html. So after serviceworker takes over, serves index.html from cache.
- The index.html declares the AppCache manifest and when served from cache, it seems that AppCache kicks in again and you can see the update checking and all events from it, while the serviceworker is active.

I made a workaround in the service worker script that :
1. when I cache index.html I modify the stream and remove the manifest attribute
2. when the manifest file is requested I return 404
Those two things effectively clear the appcache cached entries

Hope this helps

Comment 37 by, Jan 15 2017

Hi falken@, I created am example here:

This page has both a service worker running and application cache manifest but Chrome continues to trigger application cache events (updateready in this example) and throw an error on swapCache.

A timestamp on the application cache manifest ensures an application cache update event should occur every second on soft refresh to test updateready event and swapCache error.

Comment 38 by, Jan 20 2017

To skip appcache updates, couldn't the server avoid inserting the manifest url by doing a user agent check?

Our concern, is that a fix to this has to potential to break things:
- We currently monitor appcache while updating, and we'd really like to avoid sinking more time into code we want to get rid of.
- This fix should make sure that appcache on the same domain but on other scopes will still work because we will be using both during the rollout period.
- We would rather be able to update both SW and appcache simultaneously, so in case we need to trigger a kill switch for service workers, we would still be able to fallback on a fresh appcache.
- We would like to be able to control when AppCache gets deleted, and the only way to do it is to update AppCache and return 404 for the manifest.

Comment 39 by, Jan 20 2017

Agreed to all points in above comment by ralp@.

Plus that in our case, we have static index.html files which contain a manifest.
We wouldn't like to have to implement/modify them dynamically on the server side.
And the UA string is not a reliable thing anyways.

Comment 40 by, Jan 20 2017

Construct 2 builds HTML5 games entirely client-side, and uses both AppCache and SW to cover cross-browser offline support. We have no control over the server-side, so we cannot change whether the manifest url is present in the downloaded HTML. We could however add it at runtime if SW support is not available. Would that still work correctly for appcache?
Status: Assigned (was: Started)
First of all, thanks to kyle and ps for the repro steps, and thanks to everyone for the feedback.

ps@, you say you agree with all of ralphch's comment, but that comment seems to argue for a WontFix (or rather urges caution toward a fix) for this bug. I agree any fix here will indeed need careful consideration of its consequences.

ash@, I don't know if adding the manifest at runtime works for AppCache. Someone would have to test this (or maybe michaeln@ knows off-hand).

Sign in to add a comment