Broken in Safari 14 ?

[bbsimonbb]

This appears not to be working for me in Safari 14. I'm a bit hampered because my app doesn't have a build step, but I've got it working for Chrome. In safari, I can follow with the debugger into the service worker. Something is happening, but the debugger bounces around and the result is inconsistent. Sometimes some offline functionality is available. I'm tearing my hair out.

[jeffposnick]

I was going to say that I recently saw a similar question on Stack Overflow... but it looks like that was from you 😄

If your web app fundamentally doesn't work with AppCache, without this service worker tooling added, then I think that's a bug to raise with the WebKit team. If something broke related to the core AppCache implementation in Safari 14 (where AppCache, I believe, is still meant to be implemented), I could imagine that might also affect the initialization of this polyfill library.

[bbsimonbb]

I've narrowed this down a bit. I believe our issue is due to different behaviour for urls with an anchor. Chrome will happily understand that a request for myOfflinePage.html#someAnchor corresponds to the app-cache entry myOfflinePage.html. App cache behaves like this. Safari however wants the url to match exactly, and the anchor breaks it. Can we fix this in the polyfill ?

[jeffposnick]

I'd hesitate to explicitly fix it in the polyfill if it's a bug that Apple inadvertently introduced in Safari 14. Can you go the route of filing a WebKit bug with reproduction detail, ideally just involving AppCache, and not this polyfill, i.e. as basic as possible? If it turns out that this is an intentional change and it does make sense to special-case the logic in the polyfill somehow, then we can revisit.