892370 - can't open long IDN domain

Status: VERIFIED FIXED

(Core :: Networking: DNS, defect)

Description

[Bee Amorndaet]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:22.0) Gecko/20100101 Firefox/22.0 (Beta/Release)
Build ID: 20130618035212

Steps to reproduce:

I can open all of this domain with firefox

[http://ไฮดรอลิกไฮโดรลิก.com] , [http://วอลเปเปอร์-ติดผนัง.net] , [http://ลังพลาสติกลังทึบ.com] 

But I can't open all of this domain

[http://เครื่องทำน้ำทำน้ำแข็ง.com] , [http://เครื่องพ่นสีเครื่องพ่นสีฝุ่น.com] ,[http://อลูมิเนียมอลูมิเนียมห้องเย็น.com] 

and many other domain with long charactor it can't open with firefox but can open with google chrome , internet explorer


Actual results:

Server not found
        
          Firefox can't find the server at www.เครื่องพ่นสีเครื่องพ่นสีฝุ่น.com.


Expected results:

Open all IDN domain with long or short name.

Comment 1

[Andre Klapper]

(In reply to Bee Amorndaet from comment #0)
> But I can't open all of this domain
> [http://เครื่องทำน้ำทำน้ำแข็ง.com] ,
> [http://เครื่องพ่นสีเครื่องพ่นสีฝุ่น.com]
> ,[http://อลูมิเนียมอลูมิเนียมห้องเย็น.com] 

I can open them with Firefox 18 without problems.

Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems. It does not disable plugins which are add-ons.) See http://support.mozilla.com/en-US/kb/Safe+Mode 

And does this also happen with a new and empty profile? See http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-profile and http://support.mozilla.org/kb/Managing%20profiles . 

If you still see this problem in the new profile, please enter the address "about:support" in the address bar and attach (using the "Add an attachment" link above) the output for your original profile (not the new profile), as the "Modified Preferences" section could be interesting. 
Thanks for your help!

Comment 2

[Loic]

Regression range:
good=2013-03-04
bad=2013-03-05
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=86c98c4d36da&tochange=015da7030aab

Suspected bug:
Simon Montagu — Remove network.enableIDN pref. Bug 842282, r=honza.b

Workaround:
network.IDN_show_punycode=true fixes the issue.

Anyway, is it a valid regression?

Comment 3

[Bee Amorndaet]

Attachment: raw data of "about:support" of my browser

Comment 4

[Bee Amorndaet]

(In reply to Andre Klapper from comment #1)
> (In reply to Bee Amorndaet from comment #0)
> > But I can't open all of this domain
> > [http://เครื่องทำน้ำทำน้ำแข็ง.com] ,
> > [http://เครื่องพ่นสีเครื่องพ่นสีฝุ่น.com]
> > ,[http://อลูมิเนียมอลูมิเนียมห้องเย็น.com] 
> 
> I can open them with Firefox 18 without problems.
> 
> Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode
> disables extensions and themes, hardware acceleration and some JavaScript
> stuff in order to exclude some possible reasons for problems. It does not
> disable plugins which are add-ons.) See
> http://support.mozilla.com/en-US/kb/Safe+Mode 
> 
> And does this also happen with a new and empty profile? See
> http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-
> profile and http://support.mozilla.org/kb/Managing%20profiles . 
> 
> If you still see this problem in the new profile, please enter the address
> "about:support" in the address bar and attach (using the "Add an attachment"
> link above) the output for your original profile (not the new profile), as
> the "Modified Preferences" section could be interesting. 
> Thanks for your help!

1.I try open that web in safe mode >> Same result (can't open long IDN domain)
2.My firefox and my friend computer never use profile
3.Now I upload attachment for raw data of my browser

Thank.

Comment 5

[Bee Amorndaet]

(In reply to Loic from comment #2)
> Regression range:
> good=2013-03-04
> bad=2013-03-05
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=86c98c4d36da&tochange=015da7030aab
> 
> Suspected bug:
> Simon Montagu — Remove network.enableIDN pref. Bug 842282, r=honza.b
> 
> Workaround:
> network.IDN_show_punycode=true fixes the issue.
> 
> Anyway, is it a valid regression?

I try to change config 
network.IDN_show_punycode=true

That can solve this problem.

Comment 6

[Gervase Markham [:gerv]]

Wireshark seems to suggest we aren't even making a DNS request here, and therefore something is going wrong with the Thai -> punycode conversion. smontagu: looks like one for you.

Loic: thank you for the regression range finding, although I have no idea why that change would cause this problem...

Gerv

Comment 7

[Loic]

(In reply to Gervase Markham [:gerv] from comment #6)
> Loic: thank you for the regression range finding, although I have no idea
> why that change would cause this problem...

I tested with old FF17:
+ network.enableIDN = true: FF17 is able to load the websites
+ network.enableIDN = false: FF17 fails

So removing the pref affects the way to load these websites.

Comment 8

[Simon Montagu :smontagu]

Attachment: Patch

Pending try results at https://tbpl.mozilla.org/?tree=Try&rev=92cf7cc03f19

Comment 9

[Simon Montagu :smontagu]

Attachment: Updated patch with test

Comment 10

[Honza Bambas (:mayhemer)]

Simon, can you please explain the changes in detail?  I've already forgot how all this code works.  Thanks.

Comment 11

[Honza Bambas (:mayhemer)]

See comment 10.

Comment 12

[Simon Montagu :smontagu]

Attachment: Patch with more comments

I reckon if the reviewer needs to ask it's worth putting the answer in a code comment. Let me know if this still isn't clear.

I'm beginning to think this code is too overloaded and it would be better to separate out the conversions for display and for ACE/DNS, at the expense of some duplication. What do you think?

Comment 13

[Honza Bambas (:mayhemer)]

Comment on attachment 779083 [details] [diff] [review]
Patch with more comments

Review of attachment 779083 [details] [diff] [review]:
-----------------------------------------------------------------

r=honzab

Thanks for the explanation.

::: netwerk/dns/nsIDNService.cpp
@@ +641,5 @@
> +    // DNS node per RFC 1034.
> +    // This test isn't necessary in the code paths above where the input is
> +    // ASCII (since the output will be the same length as the input) or where
> +    // we convert to UTF-8 (since the output is only used for display in the
> +    // UI and not passed to DNS and can legitimately be longer than the limit).

Could happen we might send the result in other cases to DNS?  It's hard to believe the code can ensure it, but I don't know the IDN stuff that well.  It's just the impression.

Comment 14

[Lukas Blakk [:lsblakk] use ?needinfo]

This didn't land in time for FF23, wontfixing.

Comment 15

[Simon Montagu :smontagu]

https://hg.mozilla.org/integration/mozilla-inbound/rev/1e8481e37d06

Comment 16

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/1e8481e37d06

Comment 17

[bhavana bajaj [:bajaj]]

needinfo Simon, to help with uplift.

Comment 18

[Simon Montagu :smontagu]

Comment on attachment 779083 [details] [diff] [review]
Patch with more comments

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Exposed by bug 842282 for the specific domains in the testcase, but the root problem was caused by bug 722299
User impact if declined: Some domains will be inaccessible (though a workaround via about:config does exist)
Testing completed (on m-c, etc.): Baked on m-c since 2013-07-30, and on aurora since the ff25 uplift
Risk to taking this patch (and alternatives if risky): I don't see a potential for serious regression
String or IDL/UUID changes made by this patch: None

Comment 19

[Simon Montagu :smontagu]

https://hg.mozilla.org/releases/mozilla-beta/rev/48b14885dcce

Comment 20

[Matt Wobensmith [:mwobensmith][:matt:]]

Confirmed broken in FF23. Also confirmed broken in pre-patch FF24 2013-07-10.

Verified fixed in FF24 and FF25, 2013-08-26.

Comment 21

[Simon Montagu :smontagu]

needinfo provided in comment 18