search

GoogleChromeLabs / sw-appcache-behavior

A service worker implementation of the behavior defined in a page's AppCache manifest.
Apache License 2.0
54 stars 15 forks source link

Make the name of the 'manifest' attribute configurable #22

Closed gae123 closed 4 years ago

gae123 commented 4 years ago

I found this project very useful to transition an application from appCahce to service workers. During the transitioning, I run into the following issue:

Recent versions of chrome get pretty agitated when they see the manifest attribute because they take that as a sign that the app is still using the application cache.

I worked around this issue employing the following hack: On the server side I renamed manifest to app-cache-manifest. This quiets down chrome. However, the sw-appcache-behavior framework now does not work because it expects to find an attribute called manifest to read the manifest file from.

So I added these two lines to make everything work:

...
const manifestPath = document.documentElement.getAttribute("app-cache-manifest")
document.documentElement.setAttribute("manifest", manifestPath)
appcachePolyfill.init(
...

So I was thinking, what about making the attribute name configurable. It defaults to manifest for backwards compatibility but in the API the user can provide a different name. If it sounds good I could submit a PR...

jeffposnick commented 4 years ago

I'm glad you found this useful!

Recent versions of chrome get pretty agitated when they see the manifest attribute because they take that as a sign that the app is still using the application cache.

Chrome will log some errors, yes, but does this actually affect the end-user experience? In particular, as soon as there's a service worker registered, I believe that Chrome disables any AppCache behavior, even if you are opted-in to the reserve origin trial.

gae123 commented 4 years ago

@jeffposnick I am not sure what the browser does, in fact it would be good for chrome to document the exact behavior, so it does not change one day. In any case, we strive for no errors/warnings in the console, this is what provoked this issue. My workaround seems to work fine for now, and is documented here, so we can move on for now.