Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Issue 410665 appcache is being created and updated even though service worker causes it to be bypassed
Starred by 25 users Project Member Reported by kenjibaheux@chromium.org, Sep 4 2014 Back to list
Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug



Sign in to add a comment
Based on https://github.com/slightlyoff/ServiceWorker/issues/275:

"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++."

 
Cc: falken@chromium.org
Owner: michaeln@chromium.org
Michael, Matt, did I see a patch being reviewed related to Service Worker, AppCache interation?
Michael's patch is at https://codereview.chromium.org/625433002/ -- it seems it still needs more work.
Status: Started
Sounds like it is in progress.
Project Member Comment 4 by bugdroid1@chromium.org, Oct 21 2014
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3

commit 22390646e70aba2bb8e90688f9a6351f9571bca3
Author: michaeln <michaeln@chromium.org>
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.

BUG=410665

Review URL: https://codereview.chromium.org/625433002

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

[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/appcache/appcache_host.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/appcache/appcache_host.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/appcache/appcache_interceptor.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/appcache/appcache_interceptor.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/appcache/appcache_request_handler.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/appcache/appcache_storage_impl_unittest.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/service_worker/service_worker_provider_host.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/service_worker/service_worker_request_handler.cc
[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/service_worker/service_worker_request_handler.h
[modify] https://chromium.googlesource.com/chromium/src.git/+/22390646e70aba2bb8e90688f9a6351f9571bca3/content/browser/storage_partition_impl_map.cc

> "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 michaeln@google.com, Oct 24 2014
Yes, sounds like a nice to have feature.
Comment 9 by falken@chromium.org, 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.)


Ref: https://sites.google.com/a/chromium.org/dev/developers/ticket-milestone-punting-1
Cc: michaeln@chromium.org
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.
Cc: ksakamoto@chromium.org
It seems that AppCache is not completely bypassed. Sakamoto-san might have a repro.
Here's what I saw today:

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

Owner: michaeln@chromium.org
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!

-Anthony
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 kylebar...@me.com, 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 p...@pskintzos.net, 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 a...@scirra.com, Sep 14 2016
Note this issue affects the latest release of Construct 2 (www.scirra.com), which uses SW for offline support with fallback to AppCache for other browsers.
Cc: -falken@chromium.org
Labels: -M-49 M-57
Owner: falken@chromium.org
Status: Started
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: https://mattto.github.io/sw/test/sw-and-appcache/



Comment 27 by p...@pskintzos.net, Dec 16 2016
Your appcache manifest is not correct. It should include index.html (so that the site can work offline)

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

NETWORK:
*

CACHE:
./index.html
./abe.png
./compass.jpg
./stamp.jpg
---------------------------------------------

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 p...@pskintzos.net, 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 https://mattto.github.io/sw/test/sw-and-appcache/index.html. 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. https://mattto.github.io/sw/test/sw-and-appcache/example.appcache
Comment 31 by p...@pskintzos.net, 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
Hi falken@, can you give the weekend to work on a repro?
kylebarrow@: Sure, that'd be super appreciated.
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
Hi falken@, I created am example here: https://barrow.io/lab/appcache.html

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.



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