Test that writing location.hash automatically encodes hash #17807
Conversation
Writing location.hash should invoke the standard URL encoding rules which encodes all non URL code points with percent-encoding.
wpt-pr-bot
requested review from
annevk,
domenic,
foolip,
jdm,
jgraham,
zcorpan and
zqzhang
|
Is there any spec issue raised about the difference between implementation and spec? |
|
I have not raised a spec issue, though this is inconsistent. Chrome and Firefox have the behavior expected in these new tests, Safari and Edge do not automatically encode non URL code points unless the URL is navigated to in a new tab. I think that this expected behavior is correct to spec[1, 2] and also matches my expectation as a developer that what I read back as the hash is the same as if the link is shared. However, I'm mostly interested in standardizing the behavior whatever the correct behavior should be :-). [1] https://html.spec.whatwg.org/#the-location-interface |
|
testharness.js offers an -test(function() {
+test(function(t) {
+ t.add_cleanup(function() {
+ location.hash = "";
+ });
location.hash = "test";
assert_equals(location.hash, "#test");
- location.hash = "";
}, "Setting hash should automatically include hash character");The cleanup logic doesn't seem critical here, so this patch is probably fine as written. Sharing this mostly as general good-to-know information |
There was a problem hiding this comment.
The tests seem fine, though per the rules of https://url.spec.whatwg.org/#fragment-state, not those cited by OP earlier. However, if setting is not synchronous that's a problem.
| @@ -10,6 +10,9 @@ | |||
| <iframe id="srcdoc-iframe" | |||
| srcdoc="<div style='height: 200vh'></div><div id='test'></div>"></iframe> | |||
| <script> | |||
| //**This test assumes that assignments to location.hash will be synchronous - this is how all browsers implement it. | |||
| //The spec (as of 25 March 2011) disagrees. | |||
There was a problem hiding this comment.
If this is true, we should track this with an issue against whatwg/html.
There was a problem hiding this comment.
FWIW, I didn't personally test/verify this statement beyond seeing that all major browsers seem to do this, but this comment is in 001.html and 002.html from the history interface tests:
https://github.com/web-platform-tests/wpt/search?q=%22This+test+assumes+that+assignments+to+location.hash+will+be+synchronous%22&unscoped_q=%22This+test+assumes+that+assignments+to+location.hash+will+be+synchronous%22
This test didn't seem to belong in the history interface though - so I copied it here. I can open a spec issue.
There was a problem hiding this comment.
As far as I can tell the specification also does synchronous navigation for fragment changes though.
There was a problem hiding this comment.
Those are very old tests, so probably best not to copy-and-paste information from them.
There was a problem hiding this comment.
Okay, I've removed the comment in the latest commit. I can also of course remove it from the other tests if you think it would be good to clean up.
Thanks for the correct spec link.
Would you prefer I convert to an asynchronous test pattern using the hashchange event? |
Writing location.hash should invoke the standard URL encoding rules which encodes all non URL code points with percent-encoding.