Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Test that writing location.hash automatically encodes hash #17807

Merged
merged 2 commits into from Jul 19, 2019

Conversation

@flackr
Copy link
Contributor

flackr commented Jul 12, 2019

Writing location.hash should invoke the standard URL encoding rules which encodes all non URL code points with percent-encoding.

Writing location.hash should invoke the standard URL encoding rules
which encodes all non URL code points with percent-encoding.
@jdm

This comment has been minimized.

Copy link
Contributor

jdm commented Jul 12, 2019

Is there any spec issue raised about the difference between implementation and spec?

@flackr

This comment has been minimized.

Copy link
Contributor Author

flackr commented Jul 12, 2019

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
[2] https://url.spec.whatwg.org/#url-writing

@jugglinmike

This comment has been minimized.

Copy link
Contributor

jugglinmike commented Jul 12, 2019

testharness.js offers an add_cleanup function which lets you run code after a test regardless of its passing/failing status.

-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

Copy link
Member

annevk left a 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.

This comment has been minimized.

Copy link
@annevk

annevk Jul 15, 2019

Member

If this is true, we should track this with an issue against whatwg/html.

This comment has been minimized.

Copy link
@flackr

flackr Jul 15, 2019

Author Contributor

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.

This comment has been minimized.

Copy link
@annevk

annevk Jul 16, 2019

Member

As far as I can tell the specification also does synchronous navigation for fragment changes though.

This comment has been minimized.

Copy link
@annevk

annevk Jul 16, 2019

Member

Those are very old tests, so probably best not to copy-and-paste information from them.

This comment has been minimized.

Copy link
@flackr

flackr Jul 16, 2019

Author Contributor

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.

@flackr

This comment has been minimized.

Copy link
Contributor Author

flackr commented Jul 15, 2019

The tests seem fine, though per the rules of https://url.spec.whatwg.org/#fragment-state, not those cited by OP earlier.

Thanks for the correct spec link.

However, if setting is not synchronous that's a problem.

Would you prefer I convert to an asynchronous test pattern using the hashchange event?

@annevk
annevk approved these changes Jul 19, 2019
@annevk annevk merged commit 30780f8 into web-platform-tests:master Jul 19, 2019
8 checks passed
8 checks passed
Azure Pipelines Build #20190716.57 succeeded
Details
Azure Pipelines (./wpt test-jobs) ./wpt test-jobs succeeded
Details
Azure Pipelines (affected tests without changes: Safari Technology Preview) affected tests without changes: Safari Technology Preview succeeded
Details
Azure Pipelines (affected tests: Safari Technology Preview) affected tests: Safari Technology Preview succeeded
Details
Azure Pipelines (wpt.fyi hook: safari-preview-affected-tests) wpt.fyi hook: safari-preview-affected-tests succeeded
Details
Taskcluster (pull_request) TaskGroup: success
Details
wpt.fyi - chrome[experimental] Chrome results
Details
wpt.fyi - firefox[experimental] Firefox results
Details
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.