Created attachment 374014 [details] Demo of inconsistent hash readback. When Javascript sets the location hash, it reads back as the exact string which Javascript set. This seems to remain even if the page is reloaded. However, if the user copies the URL to another tab, the string is URL encoded resulting in a different location.hash read from Javascript. This results in a subtle bug if the developer does not explicitly encode / decode the location hash. See https://output.jsbin.com/jikefe for live demo or the following: <!DOCTYPE html> <body> <div id="log"></div> </body> <script> document.addEventListener('DOMContentLoaded', function() { if (window.location.hash == '') window.location.hash = 'test encoding'; else hashchange(); }); function hashchange() { document.getElementById('log').textContent = window.location.hash; } window.addEventListener('hashchange', hashchange); </script> When the demo site sets the location hash it is read back with a space in Safari 12 and Edge 18, in Chrome and Firefox the value read back is url encoded which it will be if the URL is copied to another tab.
FYI I've created a web-platform-tests PR here: https://github.com/web-platform-tests/wpt/pull/17807
<rdar://problem/53034220>
Created attachment 459866 [details] Safari 15.5 matches other browsers Based on testing with Safari 15.5, now due to Spec change or browser changes on handling URL encoding, all browsers now behave same based on the test case. Hence, I think this should be marked as "Resolved Fixed". Thanks!
Thank you for checking! We have this WPT test imported now, and it passes.