Closed Bug 892370 Opened 6 years ago Closed 6 years ago

can't open long IDN domain

Categories

(Core :: Networking: DNS, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla25
Tracking Status
firefox22 --- wontfix
firefox23 + wontfix
firefox24 + verified
firefox25 + verified

People

(Reporter: b, Assigned: smontagu)

References

Details

(Keywords: regression, verifyme)

Attachments

(2 files, 2 obsolete files)

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.
(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!
Flags: needinfo?(b)
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?
Blocks: 842282
Status: UNCONFIRMED → NEW
Component: Untriaged → Networking: DNS
Ever confirmed: true
Flags: needinfo?(b)
Keywords: regression
Product: Firefox → Core
(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.
(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.
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
(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.
Assignee: nobody → smontagu
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 22 Branch → Trunk
Attached patch Patch (obsolete) — Splinter Review
Pending try results at https://tbpl.mozilla.org/?tree=Try&rev=92cf7cc03f19
Attached patch Updated patch with test (obsolete) — Splinter Review
Attachment #774588 - Attachment is obsolete: true
Attachment #775295 - Flags: review?(honzab.moz)
Simon, can you please explain the changes in detail?  I've already forgot how all this code works.  Thanks.
See comment 10.
Flags: needinfo?(smontagu)
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?
Attachment #775295 - Attachment is obsolete: true
Attachment #775295 - Flags: review?(honzab.moz)
Attachment #779083 - Flags: review?(honzab.moz)
Flags: needinfo?(smontagu)
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.
Attachment #779083 - Flags: review?(honzab.moz) → review+
This didn't land in time for FF23, wontfixing.
https://hg.mozilla.org/mozilla-central/rev/1e8481e37d06
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
QA Contact: mwobensmith
needinfo Simon, to help with uplift.
Flags: needinfo?(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
Attachment #779083 - Flags: approval-mozilla-beta?
Keywords: verifyme
Attachment #779083 - Flags: approval-mozilla-beta? → approval-mozilla-beta+
Confirmed broken in FF23. Also confirmed broken in pre-patch FF24 2013-07-10.

Verified fixed in FF24 and FF25, 2013-08-26.
Status: RESOLVED → VERIFIED
needinfo provided in comment 18
Flags: needinfo?(smontagu)
You need to log in before you can comment on or make changes to this bug.