310008 - Punycode in "could not be found" error

Status: RESOLVED INVALID

(Core :: DOM: Navigation, defect)

Description

[Jean-Sébastien Goupil]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

Type in address bar
http://www.google.com¾
or http://www.google.com¸

It will give you the following `
1) www.google.xn--com34-g33b could not be found
2) www.google.xn--com -e1c could not be found

Reproducible: Always

Comment 1

[Phil Ringnalda (:philor)]

Two hours of reading IDN bugs, and I'm not sure whether or not this has been
discussed. Gerv? Do we intentionally want to display punycode in errors for
non-whitelisted tlds, either for security or for consistency with what the
addressbar is showing? (It's filed on dialogs, I'd guess, in 1.0.x, but we do
also show punycode on trunk.)

Comment 2

[OstGote!]

What are your settings for network.enableIDN and network.IDN_show_punycode? Note
Bug 283586. 

With network.enableIDN = true & network.IDN_show_punycode = false then it shows
the error in IDN for me with Mozilla 1.7.12. But the default values are true for
both prefs, then it shows of course in Punycode. 

Comment 3

[Jean-Sébastien Goupil]

In about:config (I had to search to find that line)

network.enableIDN = true
network.IDN_show_punycode = true

Even if it is normal to show these "punycode", I don't think it is a good thing
to  show it by default.

Comment 4

[Gervase Markham [:gerv]]

Firefox 1.0.x shows punycode always, but Firefox 1.5 will not. I'm not
particularly concerned what this error says, although the ideal would be IDN for
whitelisted TLDs and punycode for others.

Gerv

Comment 5

[Adam Guthrie]

*** Bug 310332 has been marked as a duplicate of this bug. ***

Comment 6

[Phil Ringnalda (:philor)]

Okay, invalid per comment 4 then: 1.0.x shows punycode always, because that was
the best we could do back then, 1.5 shows punycode for non-whitelisted top level
domains and not for whitelisted ones, in both the urlbar and in the body of (the
default) XUL error pages, and there's already a bug on the one combination of
prefs where we could possibly be wrong.