Different content in incognito mode versus PWA

[ithinkihaveacat]

Maybe a service worker caching issue?

Incognito mode (top story: "Sean Spicer resigns…"):

PWA (top story: "Report that Trump…"):

Video: https://photos.app.goo.gl/SaaDxkYyePbO8jmQ2

[pbakaus]

Yes, this is indeed an issue with workbox, as investigated by @jeffposnick in GoogleChrome/workbox#691. I now commented out the code in question, which should fix it for now. Let me know if you're still seeing the behaviour after two reloads.

[jeffposnick]

I'm not sure what you commented out, but if you try switching from CacheFirst to StaleWhileRevalidate for that feed until we've fixed the underlying bug, you'll end up with reasonable behavior.

[pbakaus]

@jeffposnick sadly I don't think so, as that would mean that a person coming back to the app a few days later will see old stuff, no? Or does staleWhileRevalidate honor the cacheExpiration?

[jeffposnick]

So even when GoogleChrome/workbox#694 is merged they'll see old stuff on the next visit when using CacheFirst, because we don't have a Date header on the cross-origin response and therefore can't tell synchronously whether the response is fresh or not. The change in that PR will mean that the content will at least get purged in the background for the next visit.

StaleWhileRevalidate along with broadcastCacheUpdate configured to announce changes to the previously cached resource is probably the ideal configuration for this use case—you can listen for that update and then swap in the new content from the context of the page. The use of broadcastCacheUpdate for cross-origin resources also would be a problem, though, because it relies on checking Response headers, and I don't believe the Yahoo! API you're using whitelists the headers it needs...

[pbakaus]

I think I'll do networkFirst instead for now, to keep it fresh and only handle the offline use-case. Thanks for the pointers though, might play around with boradcastCacheUpdate!