This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 10410 - On getting, should the UA percent-decode document.location.hash? It's not clear.
Summary: On getting, should the UA percent-decode document.location.hash? It's not cl...
Alias: None
Product: HTML WG
Classification: Unclassified
Component: pre-LC1 HTML5 spec (editor: Ian Hickson) (show other bugs)
Version: unspecified
Hardware: Other other
: P3 normal
Target Milestone: ---
Assignee: Ian 'Hixie' Hickson
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2010-08-20 17:34 UTC by contributor
Modified: 2010-10-07 19:48 UTC (History)
7 users (show)

See Also:


Description contributor 2010-08-20 17:34:41 UTC

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

Posted from:
Comment 1 Henri Sivonen 2010-08-25 12:05:54 UTC
Note that Gecko is buggy here and has a temporary workaround for Firefox 4, since the real fix didn't fit in the release schedule.
Comment 2 Ian 'Hixie' Hickson 2010-09-28 23:22:48 UTC
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:

Per spec, there's nothing to decode, as described here:

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.
Comment 3 Aryeh Gregor 2010-09-29 20:31:32 UTC
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.
Comment 4 Ian 'Hixie' Hickson 2010-09-30 04:15:48 UTC
"#%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?
Comment 5 Adam Barth 2010-09-30 06:54:27 UTC
> "#%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:

PASS segments('http://foo/path;a??e#f#g') is '["http:","foo","0","/path;a","??e","#f#g"]'

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"].

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"].

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".
Comment 6 Ian 'Hixie' Hickson 2010-10-07 19:20:07 UTC
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:

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.
Comment 7 contributor 2010-10-07 19:21:50 UTC
Checked in as WHATWG revision r5588.
Check-in comment: add more uda examples
Comment 8 Aryeh Gregor 2010-10-07 19:48:45 UTC
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.