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.

*** This bug has been marked as a duplicate of 191054 ***

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

confirming the bug. per comment #4, I'm removing 'dupe me'.

This is a classic example of treating UTF-8 as if it's ISO-8859-1.

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.

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. ***

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.

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.

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.

Comment on attachment 143431 [details] [diff] [review] additional patch for firefox sorry for spamming

Both patches went in. For the Firefox part of the first one (that was landed before 1.6beta freeze), I got moa from bryner.

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