javascript:%20alert(document.domain) ...in the following URLs returns a punycode result in the first case and the Unicode result in the second: http://xn--diseoweb-g3a.com.uy/ http://www.müller.de/ Whether or not we've whitelisted a TLD should not affect this value, but it does, and it makes IDN domain names harder to use. This is completely inconsistent, and we should fix this, preferably for Firefox 3 in my opinion. I'm tempted to argue for blocking, but given that we've shipped with this before I'd probably lose the argument. :-\ Bug 400552 covers a somewhat similar issue with setting document.domain.

dveditz tells me this also affects document.location (and by extension window.location) as well. Our doing this at the nsIURI/nsStandardURL level doesn't really help things. :-\

https://www.w3.org/Bugs/Public/show_bug.cgi?id=26261 on HTML to define how document.domain needs to be serialized. Pretty sure that the others need to be serialized as ASCII per the URL Standard.

We no longer have a whitelist of TLDs. Well, we do, but we have an algorithm as well, and the whitelist is frozen. I can't find a working domain that displays as Punycode - anyone got one? Gerv

This is still a problem. E.g. for xn--74h.example.com.

How do you get the browser to tell you the value of document.domain in the DOM of a web page on a site which doesn't even resolve in DNS? Anyway, I agree that document.domain should be always one or the other, not a mix. Gerv

(In reply to Gervase Markham [:gerv] from comment #5) > How do you get the browser to tell you the value of document.domain in the > DOM of a web page on a site which doesn't even resolve in DNS? Add origins to build/pgo/server-locations.txt and fire up a Mochitest browser and test there.

Implementation landed in bug 1380617 (firefox 56). Got turned on in bug 1380617 (firefox 57).