[Webkit-unassigned] [Bug 199752] New: window.location.hash is not URL encoded when set from Javascript.
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Fri Jul 12 09:05:34 PDT 2019
https://bugs.webkit.org/show_bug.cgi?id=199752
Bug ID: 199752
Summary: window.location.hash is not URL encoded when set from
Javascript.
Product: WebKit
Version: Safari 12
Hardware: Unspecified
OS: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: WebCore JavaScript
Assignee: webkit-unassigned at lists.webkit.org
Reporter: flackr at chromium.org
Created attachment 374014
--> https://bugs.webkit.org/attachment.cgi?id=374014&action=review
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.
--
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20190712/d3bc2110/attachment.html>
More information about the webkit-unassigned
mailing list