Closed Bug 215797 Opened 21 years ago Closed 21 years ago

Can't open URL which has IDN from History window

Categories

(Core Graveyard :: History: Global, defect)

Product:
Core Graveyard
Component:
History: Global
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED

People

(Reporter: hidenosuke, Assigned: jshin1987)

References

(
URL
)

Details

(Keywords: intl)

Attachments

(3 files, 1 obsolete file)

Screenshot of Histroy window
40.41 KB, image/png
Details
patch
2.27 KB, patch
benjamin
: review+
darin.moz
: superreview+
Details | Diff | Splinter Review
additional patch for firefox
2.45 KB, patch
benjamin
: review+
bryner
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030811 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.5b) Gecko/20030811 You can't open the URL which has IDN by double clicking the history. Reproducible: Always Steps to Reproduce: 1. Open http://ÆüËܸì¥É¥á¥¤¥ó̾¶¨²ñ.jp/ 2. Open History window 3. Double click "http://ÆüËܸì¥É¥á¥¤¥ó̾¶¨²ñ.jp/" Actual Results: Can't open the URL. Dialog displays below URL http://%c3%a6%c2%97%c2%a5%c3%a6%c2%9c%c2%ac%c3%a8%c2%aa%c2%9e%c3%a3%c2%83%c2%89%c3%a3%c2%83%c2%a1%c3%a3%c2%82%c2%a4%c3%a3%c2%83%c2%b3%c3%a5%c2%90%c2%8d%c3%a5%c2%8d%c2%94%c3%a4%c2%bc%c2%9a.jp/ Expected Results: Can open the URL from History window. Is encoding to punycode bad? Dragging the URL from History window and dropping it to Browser window then it's OK, anyway.
Original report in Bugzilla-jp is http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=3277
This is a duplicate of the "history interfaces are ascii-only" bug.
Whiteboard: DUPEME
*** This bug has been marked as a duplicate of 191054 ***
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → DUPLICATE
In this case the URL is displayed correctly. I don't think this is dup of bug 191054. Please test again.
Sorry, was just listening to Boris there. REOPENING
Status: RESOLVED → UNCONFIRMED
Resolution: DUPLICATE → ---
confirming the bug. per comment #4, I'm removing 'dupe me'.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: intl
Whiteboard: DUPEME
This is a classic example of treating UTF-8 as if it's ISO-8859-1.
Assignee: firefox → jshin
Depends on: 234392
UTF-8 strings are converted to UTF-16 with 'zero-padding' at http://lxr.mozilla.org/seamonkey/source/xpfe/components/history/resources/history.js#278 Because |Value| attribute in nsIRDFResource is 'string' instead of 'AUTF8String', crossing the XPConnect boundary, it's elevated to UTF-16 with 'zero-padding'. http://lxr.mozilla.org/seamonkey/source/rdf/base/idl/nsIRDFResource.idl#51 If fixing nsIRDFResource is not feasiblie in the near future (bug 234392), I may roll out a dirty hack in history.js to recover the original value from a 'zero-padded' UTF-16 string.
This is a hardware/OS ALL/ALL bug, please change that. I'm on WinNT4. Same thing with other IDN like ones containing umlauts. Visit http://öko.de/ and try to load it from the history. Due to the wrong conversions it tries to load http://xn--ko-wea3p.de/ (= http://öko.de/) instead of the correct http://xn--ko-eka.de/. See related bug 236208.
Sure, I should've done it.
OS: Linux → All
Hardware: PC → All
Bug 236208 is fixed, but this problem is still reproducible. Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7b) Gecko/20040305
What led you to believe that fixing bug 236208 would fix this as well?
*** Bug 236569 has been marked as a duplicate of this bug. ***
Attached patch patch — — Splinter Review
I think this should work now that bug 234392 has been fixed. I have yet to test it, though.
Comment on attachment 143405 [details] [diff] [review] patch Asking for r/sr. I've just built ff with this patch and it works fine.
Attachment #143405 - Flags: superreview?(darin)
Attachment #143405 - Flags: review?(bsmedberg)
Attachment #143405 - Flags: superreview?(darin) → superreview+
Attachment #143405 - Flags: review?(bsmedberg) → review+
Attached patch additional patch for firefox (obsolete) — — Splinter Review
I should file a new bug (because this bug was fixed in both mozilla and ff), but let me just get away with this (this three-line patch all involves the same Value -> ValueUTF8 change.). After checking in attachment 143405 [details] [diff] [review], I found firefox supports more 'operations' on history entries than mozilla does.
I should file a new bug (because this bug was fixed in both mozilla and ff), but let me just get away with this (this three-line patch all involves the same Value -> ValueUTF8 change.). After checking in attachment 143405 [details] [diff] [review], I found firefox supports more 'operations' on history entries than mozilla does.
Comment on attachment 143432 [details] [diff] [review] additional patch for firefox asking for r/sr. sorry for adding the same patch twice.
Attachment #143432 - Flags: superreview?(bryner)
Attachment #143432 - Flags: review?(bsmedberg)
Comment on attachment 143432 [details] [diff] [review] additional patch for firefox I think this was already checked in, but marking sr+ to get off my list.
Attachment #143432 - Flags: superreview?(bryner) → superreview+
Comment on attachment 143431 [details] [diff] [review] additional patch for firefox sorry for spamming
Attachment #143431 - Attachment is obsolete: true
Attachment #143432 - Flags: review?(bsmedberg) → review+
Both patches went in. For the Firefox part of the first one (that was landed before 1.6beta freeze), I got moa from bryner.
Status: NEW → RESOLVED
Closed: 21 years ago → 21 years ago
Resolution: --- → FIXED
*** Bug 238387 has been marked as a duplicate of this bug. ***
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: