The URL Hash is store in the AppCache database and it does not allow an appcached page to be loaded from appcache with a different fragment from the one it was initially loaded with. Steps to reproduce: 1. Create a Hello World style webpage and a manifest that has no entries in it. 2. Open the page and change the URL hash to #foo 2. Do a browser refresh (to put it into AppCache) 3. Go offline 4. Do a browser refresh and ensure the page refreshes from AppCache. 5. Change the URL hash to #bar 6. Do a browser refresh and notice that it fails to load.
<rdar://problem/7029995>
I also opened a radar bug for this (sorry for not mentioning it before): <rdar://problem/7027850> Also, I've found an existing hello world style page to test against: http://www.thecssninja.com/demo/offline_webapp/index.html
I think that the behavior is correct per the current spec - it never says that fragments should be ignored when loading resources, or when storing implicit resources. It only says that fragments should be ignored on URLs in manifests, as far as I can see. But I also think that the desired behavior is to ignore them.
I think the spec has a bug if that's what it says case :)
http://www.whatwg.org/specs/web-apps/current-work/#parsing-cache-manifests The spec says to drop the fragment identifier part of any URLs parsed in the manifest.
Nevermind, I understand now. Yeah, this is wrong in the spec.
Created attachment 32687 [details] proposed fix
Comment on attachment 32687 [details] proposed fix r=me Should we use KURL more and String less?
Committed <http://trac.webkit.org/changeset/45848>. (In reply to comment #8) > Should we use KURL more and String less? Probably not worth it in most cases here, as they only check hasRef() in debug builds.
spec is fixed
Oops, forgot to mark this bug as fixed: <http://trac.webkit.org/projects/webkit/changeset/45848>.