40608 - text/unicode used in drag and drop not a valid IANA media type

Status: RESOLVED INACTIVE

(Core :: XUL, defect, P3)

Description

[Christopher Blizzard (:blizzard)]

The data type that we are using to move around unicode strings isn't an actual
registered mime type.  The valid registered types listed are here:

ftp://ftp.isi.edu/in-notes/iana/assignments/media-types/media-types

we should probably change it to text/x-moz-unicode or figure out if there's a
better way to describe text/plain with some kind of content encoding.  Are there
any platform specific restrictions here?  Do some platforms require
text/unicode?

Comment 1

[Mike Pinkerton (not reading bugmail)]

okies.

Comment 2

[Peter Trudelle]

Mass-moving all M20-M30 XPToolkit bugs to Future

Comment 3

[Jesse Ruderman]

what does unicode look like if you view it in a text editor?

Comment 4

[Mike Pinkerton (not reading bugmail)]

on win32, it becomes the CF_UNICODE data flavor which can be viewed in word or 
notepad. for apps that don't understand unicode, like wordPad it is translated to 
CF_TEXT.

Comment 5

[Christopher Blizzard (:blizzard)]

Is it Mozilla or the app change changes it from text/unicode -> CF_UNICODE?

Comment 6

[Mike Pinkerton (not reading bugmail)]

mozilla does this internally.

Comment 7

[Peter Trudelle]

->pinkerton.  Is this causing any defective behavior?

Comment 8

[otaylor]

It doesn't matter much (to me) what mozilla does internally, but text/unicode
is being exported to other X apps through the Xdnd specifcaiton, and other
apps cannot be expected to support made up mimetypes.

What should be exported through Xdnd is at least:

 UTF8_STRING (http://www.pps.jussieu.fr/~jch/software/UTF8_STRING/)

And probably some valid mime type for what text/unicode represents.
"text/plain; charset=utf-16[be/le]" seems like a candidate; rfc 2781
mentions that utf-16 can't be used as a charset
for text/ subtypes because it doesn't represent CR LF as CR LF,
but then goes ahead and says it's legitimate to do so for HTTP
as an exception, so perhaps it could be justified here as well.

Comment 9

[Simon Montagu :smontagu]

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

Comment 10

[Simon Montagu :smontagu]

Transferring dataloss keyword from duplicate bug.

Comment 11

[David G King]

This bug is marked as blocking Bug #106708. However, that bug has been fixed, so
does this bug still exist (yes it does as a dup has been made from a build after
the Bug #106708 fix went in), or does this bug not really block Bug #106708?

I'm just trying to keep things tidy and accurate, so comments are welcome.

Comment 12

[Andrew Hagen]

It must be the other way around for bug 106708. Resetting dependencies.

Comment 13

[Adrian Buckley]

Bug 106708 is marked OS: PC, this bug is marked OS:ALL.

That's why this bug is still open - bug 106708 was a PC only fix. This is still
an issue for other OS's.

Notes: This bug causes other incorrect behaviour (such as bug 71786), which bug
106708 does not fix. See bug 71786 comment 13 and the related attachment.

My concern is that changing this may mean rewriting large parts of Mozilla's DND
code to expect UTF8 text rather than Unicode.

Adding this as blocking Bug 71786.

Comment 14

[Brant Gurganus]

By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.

Comment 15

[Rafael Ebron (:rebron)]

adt: nsbeta1-

Comment 16

[Jan D.]

As an implementer of XDND, I would also like to point out that utf-16le is used
by mozilla on little-endian machines and utf-16be on big endian machines.  This
makes it hard for an application that receives a drop to determine what to use
(le or be).  Mozilla might very well be running on a different machine than the
drop receiving application.

I would prefer if you switched to UTF8_STRING (as GNOME and KDE now uses that),
but the alternatives in comment 8 are also ok, i.e.
"text/plain; charset=utf-16[be/le]"

Thanks.

Comment 17

[Ivan Ičin]

I wouldn't like to file duplicate, so when I drag and drop from Firefox to
OpenOffice if I get:

Kako izbeći “džank” hranu

instead of:

Kako izbeći “džank” hranu

that relates to this bug, right?

It is really horrible for non-english languages.

Comment 18

[Ari Mustonen]

GTK+ appears to assume that "text/plain" is encoded in ISO-8859-1 so
drag-and-drop from Firefox to any GTK+ application produces rubbish if the
copied text contains non-ASCII characters. Using "UTF8_STRING" or
"text/plain;charset=utf-8" as the drag type should give the correct result.

Comment 19

[Timea Cernea [:tbabos][inactive]]

Closing this bug as resolved:inactive, last update was 16 years ago. If this is still reproducible on the latest Firefox versions, please do re-open it.