This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
Section: http://www.whatwg.org/specs/web-apps/current-work/#interfaces-for-url-manipulation Comment: On getting, should the UA percent-decode? Firefox seems to say yes, Chrome/Opera no, at least for the hash. Test case (save and visit with some percent-encoded fragment): data:text/html,<!doctype html><script>alert(document.location.hash);</script> Posted from: 68.175.61.233
Note that Gecko is buggy here https://bugzilla.mozilla.org/show_bug.cgi?id=582361 and has a temporary workaround for Firefox 4, since the real fix didn't fit in the release schedule.
Is this relating just to the behaviour of location.hash and HTMLAnchorElement.hash, or is this relating to UA behaviour for jumping to the fragid? The UA behaviour is quite complex, and described here: http://www.whatwg.org/specs/web-apps/current-work/complete.html#the-indicated-part-of-the-document Per spec, there's nothing to decode, as described here: http://www.whatwg.org/specs/web-apps/current-work/complete.html#dom-uda-hash I can add an example to the table below that if that would help. cc'ing Adam as he might be respeccing the API here into some other document that HTML will then reference.
I'm talking only about the behavior in JavaScript. If I navigate to a URL ending with "#%3F", for instance, then should document.location.hash be equal to "%3F" or "?"? The same question can be asked for anchors, sure.
"#%3F" seems to be the answer per spec now, but I'll defer to Adam. If "#%3F" is the right answer, does the spec need an example to show this, or is it in fact ambiguous? If the latter, what text should be clarified?
> "#%3F" seems to be the answer per spec now, but I'll defer to Adam. I have data on all this stuff, but I haven't paged it into memory recently. Here's a test that covers this case: http://trac.webkit.org/export/LATEST/trunk/LayoutTests/fast/url/segments.html Chrome: PASS segments('http://foo/path;a??e#f#g') is '["http:","foo","0","/path;a","??e","#f#g"]' Safari: FAIL segments('http://foo/path;a??e#f#g') should be ["http:","foo","0","/path;a","??e","#f#g"]. Was ["http:","foo","0","/path;a","??e","#f%23g"]. Firefox: FAIL segments('http://foo/path;a??e#f#g') should be ["http:","foo","0","/path;a","??e","#f#g"]. Was ["http:","foo","","/path","??e","#f#g"]. Opera: FAIL segments('http://foo/path;a??e#f#g') should be ["http:","foo","0","/path;a","??e","#f#g"]. Was ["http:","foo","80","/path;a","??e","#f#g"]. IE: (untested) (Note that "PASS" is arbitrarily set to whatever Chrome does because Brett picked these test cases.) Generally, this stuff is a mess. We'd want to test IE to be sure, but it looks like the "right" answer here is "#f#g".
EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document: http://dev.w3.org/html5/decision-policy/decision-policy.html Status: Accepted Change Description: see diff given below Rationale: I've added an example, but not changed the normative reqs, since they seem clear and correct.
Checked in as WHATWG revision r5588. Check-in comment: add more uda examples http://html5.org/tools/web-apps-tracker?from=5587&to=5588
I have no real opinion on what the correct behavior is, but the example makes it clear now, so I have no further objections here.