User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 Build ID: 20111222095143 Steps to reproduce: 1. Open http://президент.рф/ 2. Click on the site logo (white text "Президент России" on blue background) 3. Open Scratchpad and execute "alert(document.location.href); alert(document.URL); alert(document.referrer);" Actual results: 3 alerts: "http://президент.рф/", "http://президент.рф/" and "http://xn--d1abbgf6aiiy.xn--p1ai/" Expected results: 3 alerts: "http://президент.рф/", "http://президент.рф/" and "http://президент.рф/"
Additionally Google Chromium does not encode idn in all cases, Opera encodes idn in all cases.
What we currently return from document.referrer is the string we actually sent to the server in the "Referer" header. The spec on this says, amongst other things: Note: In the case of HTTP, the referrer IDL attribute will match the Referer (sic) header that was sent when fetching the current page. but this text is non-normative... I've raised a spec issue to get this sorted out: http://lists.w3.org/Archives/Public/public-html/2012Feb/0046.html
Boris: Do you got a response for your raised spec issue ? bug 852796 mentions that "This works properly in Chrome since they use decoded URLs everywhere."
Yes, in example of bug 852796 which is http://ит-7.рф/test.html it works in IE10, Chrome and Opera: http://browsershots.org/http://xn---7-vlc4b.xn--p1ai/test.html
> Boris: Do you got a response for your raised spec issue ? No. I just resent it to whatwg in hopes that that will work better. > "This works properly in Chrome since they use decoded URLs everywhere." That being punycode everywhere, yes. That seems like a bug in postMessage to me, actually; I've reopened bug 852796 to track this.
This is correct per spec. See http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2013-July/040031.html