153640 - URL in ISO-2022-JP isn't escaped correctly

Status: RESOLVED WORKSFORME

(Core :: Internationalization, defect)

Description

[Koike Kazuhiko]

URL in ISO-2022-JP isn't escaped correctly.

http://wazilla.sourceforge.jp/

Click "ニュース" in this page. 2002062110-trunk/Linux escape the URL
as follows.

http://wazilla.sourceforge.jp/#%1B$B%K%e!%3C%9%1B(B


Original report in Bugzilla-jp:
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=2337

Comment 1

[Roy Yokoyama]

->nhotta.  He worked on this

Comment 2

[nhottanscp]

I have not checked RFC 2396, but I think we can leave characters unescaped if
they are not needed to be escaped.

Comment 3

[Simon Montagu :smontagu]

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

Comment 4

[Kasumi]

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

Comment 5

[Kasumi]

verified

Comment 6

[Simon Montagu :smontagu]

If bug 160908 is a duplicate of bug 153640, bug 153640 can't be a duplicate of
bug 160908.

Comment 7

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

WFM with 2002123008-trunk/WinXP.

Comment 8

[Boris Zbarsky [:bzbarsky]]

Koike Kazuhiko, is this still an issue on Linux?  The original steps to
reproduce no longer work (that text is not a link on http://wazilla.sourceforge.jp/)

Comment 9

[Justin Kerk]

The text *is* actually a link on the page, comment #0 just gives the text in
Shift_JIS (probably the reporter's system charset), and the page is in
ISO-2022-JP (and is declared as such, so it displays as Japanese text
automatically). The link is the leftmost one in the line centered underneath the
top heading banner. If you view this bug page as Shift_JIS you can see the
Japanese appearance of the text in comment #0.

That said, the link WFM on WinXP with Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

Comment 10

[Justin Kerk]

That escaping of the link isn't recognized by IE though, so I suppose there
could be an issue where we're escaping the link in a way that's internally
consistent so that it works in Firefox, but the escaping is wrong from the
perspective of some external standard. I have no idea how ISO-2022-JP anchor
escaping is supposed to work so I can't say.

Comment 11

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041001 SeaMonkey/2.0a1pre

That link is now escaped as http://wazilla.sourceforge.jp/#%E3%83%8B%E3%83%A5%E3%83%BC%E3%82%B9 with four Unicode codepoints represented each by 3 bytes in UTF-8; that UTF-8 means ニュース which is correct. I checked the page source and the href value is still in iso-2022-jp.

Marking WORKSFORME. If it doesn't work for you on a current build of Firefox 3 or SeaMonkey 2, please paste your user-agent string (from e.g. the about: page) at the top of your comment, as I did here.

Comment 12

[Boris Zbarsky [:bzbarsky]]

This needs a test.

Comment 13

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

No, this is not actually fixed. The anchor string in ISO-2022-JP document is still escaped (but not broken). They should be displayed as decoded string.

And we still have |nsTextToSubURI::UnEscapeURIForUI|. That cannot process the complex URI that has two (or more) encodings.

http://lxr.mozilla.org/mozilla/source/intl/uconv/src/nsTextToSubURI.cpp

I think that the current statusbar is not using that. So, I think I should file 2 new bugs for the statusbar display and |nsTextToSubURI::UnEscapeURIForUI| cleaning up (or remove it).

Comment 14

[Tony Mechelynck [:tonymec]]

(In reply to comment #13)
[...]
> I think that the current statusbar is not using that. So, I think I should file
> 2 new bugs for the statusbar display and |nsTextToSubURI::UnEscapeURIForUI|
> cleaning up (or remove it).
> 

I think I saw something like that by walking the blocked/blocking bugs starting at this one, but it took me some time; there ought to be a better way to get there.