125080 - mailto url with raw non-ASCII subject and mail body is not working

Status: RESOLVED WORKSFORME

(MailNews Core :: Internationalization, defect)

Description

[ji]

mailto url with raw Simplified Chinese subject and mail body is working on
Communicator Simplified Chinese 4.51, but is broken on mozilla.

Steps to reproduce:
1. Have a gb2312 page containing a link pointing to a mailto url with raw
Simplified Chinese subject and mail body. 
2. Open the page, click on the link, the Chinese subject and mail body are
corrupted on mail compose window.

A test case will be attached later.

Comment 1

[ji]

Attachment: A testing gb2312 page with mailto url.

Comment 2

[ji]

Nominating for nsbeta1.

Comment 3

[ji]

It's working on NS 6.2.1.

Comment 4

[nhottanscp]

Is the problem specific to gb2312?

Comment 5

[ji]

It seems broken with any non-ASCII.

Comment 6

[ji]

Attachment: A Shift-JIS html page containing a link pointing to a mailto url with raw Ja subject and mailbody

Comment 7

[ji]

Attachment: A latin-1 page containing a link pointing to a mailto url with raw latin-1 subject

Comment 8

[Frank Tang]

it work fine in 2002012806 window build.
 so the problem happen after that.
nsbeta1+ per triage meeting. 

Comment 9

[nhottanscp]

In NS_MakeAbsoluteURIWithCharset(), we generate raw UTF-8 for the mailto URI and
that is expected by the mail code (it was working that way in NS6.2).
Currently, it looks like the string is infrated to PRUnichar* then converted to
UTF-8 in somewhere, so the result seems to be double converted, one character
like 'á' turns to 4 bytes instead of 2 bytes.
It happens somewhere between NS_MakeAbsoluteURIWithCharset() and the mail code 
which handles mailto url.
I think it can be avoided by escaping the UTF-8 mailto URI at
NS_MakeAbsoluteURIWithCharset, or find the place where the data is converted
incorrectly, cc to darin.

Comment 10

[Darin Fisher]

my patch for bug 124042 is going to make NS_MakeAbsoluteURIWithCharset obsolete
since necko will start accepting UTF-8 URL strings.  this means that all of the
per protocol URL escaping, such as the javascript \uxxxx escaping will be moved
into the respective protocol handlers.

NS_NewURI(const char *aSpec,
          nsIURI *aBaseURI)

is becoming:

NS_NewURI(const nsAUTF8String &aSpec,
          const char *aOriginCharset,
          nsIURI *aBaseURI);

where aOriginCharset corresponds to the charset of the document from which this
URL string originated.

so, you might want to mark this bug as blocked by bug 124042.

Comment 11

[nhottanscp]

Is there any special handling needed for mailto URI? I assume not, mailto URI
already in raw (unescaped) UTF-8.

Comment 12

[Darin Fisher]

nhotta: sounds right to me.

Comment 13

[Yuying Long]

The test pages works fine with darin's build:
ftp://ftp.mozilla.org/pub/mozilla/nightly/experimental/darin

Comment 14

[Yuying Long]

Test pages work fine on 03-06 trunk build / WinME-JA and Mac OS 10.1.3.

Comment 15

[nhottanscp]

Reassign to darin.

Comment 16

[nhottanscp]

Fixed in the trunk by bug 124042.

Comment 17

[ji]

Verified as fixed with 03/20 builds.

Comment 18

[manusor]

I just tried the latin-1 attachment on Mozilla 1.0 RC3 and also on netscape
6.2.1 both on Win2k, and the extended character e-acute does not get passed to
the subject line in either of these. FYI I'm only here because I was trying to
pass a body text with the same %E9 character and couldn't get it to work.

Comment 19

[marina]

reporter, could you please attach the problematic mail because i can not see it
happening in 2002-05-24 build.Thanks.

Comment 20

[Jaime Rodriguez, Jr.]

removing nsbeta1+, as it was carried over from anothe rcomponent.

ftang - pls work with gagan, and the necko triage team to asses whether this is
work they can resolved for MachV final release.

Comment 21

[Darin Fisher]

back to untargeted for now.

Comment 22

[Darin Fisher]

WORKSFORME Netscape 7.0 Win98