Closed
Bug 892370
Opened 10 years ago
Closed 10 years ago
can't open long IDN domain
Categories
(Core :: Networking: DNS, defect)
Core
Networking: DNS
Tracking
()
VERIFIED
FIXED
mozilla25
People
(Reporter: b, Assigned: smontagu)
References
Details
(Keywords: regression, verifyme)
Attachments
(2 files, 2 obsolete files)
4.22 KB,
text/plain
|
Details | |
3.79 KB,
patch
|
mayhemer
:
review+
bajaj
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
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•10 years ago
|
||
(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
status-firefox22:
--- → affected
tracking-firefox23:
--- → ?
tracking-firefox24:
--- → ?
tracking-firefox25:
--- → ?
Component: Untriaged → Networking: DNS
Ever confirmed: true
Flags: needinfo?(b)
Keywords: regression
Product: Firefox → Core
Reporter | ||
Comment 3•10 years ago
|
||
Reporter | ||
Comment 4•10 years ago
|
||
(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.
Reporter | ||
Comment 5•10 years ago
|
||
(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•10 years ago
|
||
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 | ||
Updated•10 years ago
|
Assignee: nobody → smontagu
OS: Windows 7 → All
Hardware: x86_64 → All
Version: 22 Branch → Trunk
Assignee | ||
Comment 8•10 years ago
|
||
Pending try results at https://tbpl.mozilla.org/?tree=Try&rev=92cf7cc03f19
Updated•10 years ago
|
Assignee | ||
Comment 9•10 years ago
|
||
Attachment #774588 -
Attachment is obsolete: true
Attachment #775295 -
Flags: review?(honzab.moz)
![]() |
||
Comment 10•10 years ago
|
||
Simon, can you please explain the changes in detail? I've already forgot how all this code works. Thanks.
Assignee | ||
Comment 12•10 years ago
|
||
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 13•10 years ago
|
||
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+
Comment 14•10 years ago
|
||
This didn't land in time for FF23, wontfixing.
Assignee | ||
Comment 15•10 years ago
|
||
https://hg.mozilla.org/integration/mozilla-inbound/rev/1e8481e37d06
Flags: in-testsuite+
Comment 16•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/1e8481e37d06
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla25
Updated•10 years ago
|
QA Contact: mwobensmith
Assignee | ||
Comment 18•10 years ago
|
||
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?
Updated•10 years ago
|
Attachment #779083 -
Flags: approval-mozilla-beta? → approval-mozilla-beta+
Assignee | ||
Comment 19•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-beta/rev/48b14885dcce
Comment 20•10 years ago
|
||
Confirmed broken in FF23. Also confirmed broken in pre-patch FF24 2013-07-10. Verified fixed in FF24 and FF25, 2013-08-26.
You need to log in
before you can comment on or make changes to this bug.
Description
•