See http://bugzilla.mozilla.org/show_bug.cgi?id=169932#c3

At the time of the error message, we are still at the outer SSL layer, no HTTP has yet started, therefore we don't have a clue what charset will be used by that page. I don't know yet how one can derive the charset that should be used in that case. I don't understand yet, why it is required to know the charset to unescape an URI. I'm a bit surprised that it depends on it, I would have expected, there is a single URI escaping standard for all charsets. Where can I learn more?

cc'ing nhotta... kai: unfortunatley there are not well defined standards for intl URIs. when a URL contains an escaped non-ASCII char, you have to decide what to do with it. is it a raw binary byte? is it a character belonging to iso-latin-1? or is it perhaps belonging to some other charset? you see, in order to display a non-ASCII URL char, you have to know how to interpret it. unfortunately, we get little help from the standards here.

"intl.charset.default" can be used as a default if no other information is available. Or no unescape is also an option. How the unescaped string is used? Is that used as a static text like status bar or is it editable like url bar?

kai Can we get specific examples of domain names that contain escaped non-ascii characters? Can someone point us to the RFC regarding what's an accepted domain name?

changing obsolete psm* target to --- (unspecified)

reassign bug owner. mass-update-kaie-20120918

I don't think we're doing this with any URLs in PSM any longer.