Closed
Bug 1465229
Opened 7 years ago
Closed 7 years ago
ServiceWorkers not serving their cached content
Categories
(Core :: DOM: Service Workers, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: u618488, Unassigned)
Details
Attachments
(1 file)
3.29 KB,
application/javascript
|
Details |
User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.170 Safari/537.36 OPR/53.0.2907.57
Steps to reproduce:
setup a site that uses the attached service_worker.js file. it implements a basic stale-while-revalidate ServiceWorker.
service worker was installed in the following manner via a script tag in the body (i.e., <script type="application/javascript" charset="utf-8" src="js/main.js"></script>):
let reloading = false;
window.addEventListener('load', () => {
if(!navigator.serviceWorker) return;
navigator.serviceWorker.register('/service_worker.js').then(registration=>{
// is this a service worker that is waiting to take over?
if(registration.waiting){
updateReady(registration.waiting);
return;
}
//is this a service worker that is installing?
if(registration.installing){
trackInstalling(registration.installing);
return;
}
//has a new service worker appeared?
registration.addEventListener('updatefound', () => {
trackInstalling(registration.installing);
});
});
//if the current service worker has changed, reload this page
navigator.serviceWorker.addEventListener('controllerchange', () => {
if (reloading) return;
console.log('reloading...');
window.location.reload();
reloading = true;
});
});
//let user know service worker can update
updateReady = (worker) => {
console.log('updateReady called...');
worker.postMessage({action: 'SKIP_WAITING'})
}
//create an state change tracker for this service worker
trackInstalling = (worker) => {
console.log('trackInstalling called...');
//if this service worker finished installing, tell it to take over.
worker.addEventListener('statechange', ()=>{
if (worker.state === 'installed') {
updateReady(worker);
}
});
}
Actual results:
Firefox appears to serve from its internal browser cache instead of from the ServiceWorker's assigned cache causing all fetches to return stale content regardless of whether the ServiceWorker is updating the cached content. i.e., if i updated an h1 tag to say "HELLO WORLD" when it previously was "hello world", only the page with "hello world" would ever be returned, regardless of the ServiceWorker caching the "HELLO WORLD" page.
Expected results:
ServiceWorker responding to fetch should only return matches from the ServiceWorker's cache, not the browser cache. Updates by the ServiceWorker to its cache should be returned on subsequent site refreshes. i.e., if i updated an h1 tag to say "HELLO WORLD" when it previously was "hello world", it should show "HELLO WORLD" after subsequent refreshes after the ServiceWorker has updated its cache.
Comment 1•7 years ago
|
||
Can you make a reduced testable demo on glitch.com or something? It would make it easier to investigate more quickly.
Flags: needinfo?(erika.jonell)
NOTE: left out additional setup details (sorry, first bug report).
1) create a simple website, doesnt matter, so long as the attached service worker, or equivalent is loaded and properly serves that site.
2) make a change to that website that should be blatantly obvious (text, styling, etc.)
3) refresh the webpage twice: once so service worker re-caches the updated site, second so you should see the update
4) see that the update you should see, you do not, regardless of the number of refreshes you perform.
5) if you clear the site cache in the preferences menu (not in dev-tools), the browser should show the updated content on refresh.
Flags: needinfo?(erika.jonell)
Comment 3•7 years ago
|
||
I'm sorry, but it would help a lot if you could make a reproducible demo yourself. Otherwise we can spend a lot of time trying to reproduce and never knowing if we are testing the exact issue you are seeing. What you are describing does not sound normal given our current test suite. Again, glitch.com is a great resource for setting up a demo like this.
Flags: needinfo?(erika.jonell)
(In reply to Ben Kelly [:bkelly] from comment #3)
> I'm sorry, but it would help a lot if you could make a reproducible demo
> yourself. Otherwise we can spend a lot of time trying to reproduce and
> never knowing if we are testing the exact issue you are seeing. What you
> are describing does not sound normal given our current test suite. Again,
> glitch.com is a great resource for setting up a demo like this.
I'll make a quick 3 file repo on github. that way you can serve it locally and easily make changes without dealing with glitch or the internet.
Flags: needinfo?(erika.jonell)
Repo is up, and I verified this reproduces the issue:
https://github.com/xevrem/serviceworker_bug
you serve it however you wish, both "python -m http.server" and "http-server" via node have both worked well for myself.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Resolution: --- → INVALID
Comment 6•7 years ago
|
||
Sorry, why did you mark it invalid?
You need to log in
before you can comment on or make changes to this bug.
Description
•