24010 - feature: text/plain from an external app is restricted to ISO-8859-1

Status: VERIFIED FIXED

(Core :: Internationalization, defect, P1)

Description

[nhottanscp]

This is a cross platform problem where text/unicode is not available (e.g.
Win98).
Here is a reproducable case using MacOS.
1) Using simple text, type accent characters (e.g. option + '`' + a) or use the
KeyCaps.
2) Select the string and copy.
3) Paste to mozilla text area.
The original string not pasted, garbage instead.

Comment 1

[Mike Pinkerton (not reading bugmail)]

accepting for m14, changing summary to remove mention of xif (we don't use it on
importing text to ender)

Comment 2

[Mike Pinkerton (not reading bugmail)]

marking as a feature, this is additional work.

Comment 3

[Mike Pinkerton (not reading bugmail)]

what is the correct way to handle this? we're not actually parsing any text in 
this case so I don't want to run it through the parser with the correct charset 
like we did in the case of exporting text to the OS. Are there any mechanisms I 
can use?

Comment 4

[nhottanscp]

What we need is to convert from the platform charset to unicode. If the 
unicode conversion is not done in the clipboard code (for text/plain) then the 
conversion to be done by the caller (e.g. editor) instead.

Comment 5

[Mike Pinkerton (not reading bugmail)]

right. my question is how we can do this. I'm not familiar with what converters/
mechanisms are at my disposal ;)

Comment 6

[nhottanscp]

How about changing nsISupportsString by adding toWString? There, it can convert 
from the platform charset to unicode. So the editor can call toWString instead 
of toString.

Comment 7

[Peter Trudelle]

Putting on beta1 radar.

Comment 8

[Mike Pinkerton (not reading bugmail)]

that would make sense, I guess my main question is how would i convert it to a 
unichar string? would i have to run it through a parser or would it be enough to 
just assign it into a unicode (nsString) string?

Comment 9

[nhottanscp]

The input string (in platform charset) needs to be converted to unicode 
explicitly. The conversion to unicode is done by nsIUnicodeDecoder.
There are many examples in the current code for the usage also in the header 
file (nsIUnicodeDecoder.h).

// get the charset manager
NS_WITH_SERVICE(nsICharsetConverterManager, ccm, kCharsetConverterManagerCID, 
&rv);
// get the encoder (may want to cache this)
rv = ccm->GetUnicodeDecoder(&fileSystemCharset, &mUnicodeEncoder);
// estimate out length
rv = mUnicodeDecoder->GetMaxLength(inString, inLength, &outLength);
// allocate out buffer
// convert
rv = mUnicodeDecoder->Convert(inString, &inLength, outString, &outLength);

Comment 10

[Mike Pinkerton (not reading bugmail)]

awesome, that's exactly what i was looking for ;) thanks!

Comment 11

[Mike Pinkerton (not reading bugmail)]

P1, this is what I'm working on.

Comment 12

[leger]

Per last nights PDT mtg, putting on the PDT+ radar

Comment 13

[Mike Pinkerton (not reading bugmail)]

fixes in on all 3 platforms.

Comment 14

[Teruko Kobayashi]

I tested this in 2000020410 Win32, Mac build, and 2000020408 Linux build.  

Comment 15

[Leif Halvard Silli]

Should this bug be reopened again, or is it the same bug as Bug 10816 (about support for UTXT on the Mac clipboard) and thus being fixed by the UTXT-patch from nhotta. ? Because, as I mentioned when I filed Bug 79864: if yo try to import e.g. cyrillic text via the clipboard from external app, it will be pasted into Mozilla as meaningless "ISO-8859-1"  instead.

Comment 16

[nhottanscp]

This bug is for adding charset conversion to support to clipboard so non Latin1
characters can be supported. This is fixed.
The conversion is dependent to OS charset but that is a separate issue from this
bug. Bug 10816 addresses that issue by supporting unicode clipboard, or in case
related issues (of text/plain) not covered by but 10816 please file a separate bug.