GNOME Bugzilla – Bug 382824
Dragging non-ascii text from gecko to GtkEntry sometimes inserts invalid UTF-8
Last modified: 2007-04-15 16:00:21 UTC
Steps: 1. Select some text containing non-ASCII characters. 2. Drag that text selection to a GtkEntry. Observe how all non-ASCII characters are replaced with "?". When doing this on Epiphany it says: (epiphany:2589): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() (epiphany:2589): GLib-CRITICAL **: g_utf8_casefold: assertion `str != NULL' failed But it must be a GTK bug because I can reproduce it on any GtkEntry.
Confirming with testentrycompletion by dragging text from epiphany. (lt-testentrycompletion:23228): Pango-WARNING **: Invalid UTF-8 string passed to pango_layout_set_text() Trace:
+ Trace 92052
dnd-list shows the following targets offered: text/_moz_htmlcontext text/_moz_htmlinfo text/html text/unicode text/plain
It works fine in gtk-demo's Entry Completion and in xchat, when dragging Russian text. What text do you need to reproduce it?
Still reproducible here with gtk+ svn trunk. Using this bug report in epiphany as source, I dragged the text "Björn" from commenter 0's name to any gtkentry or gtktextview in another application. (The critical comes from the target application, not from epiphany.)
Got it, you need to drag text from mozilla (and I tried from gtktextview first). So it's not just "non-ASCII and GtkEntry", it has to do with source too.
Well, there might be a bug in the source too, but definitely gtk shouldn't insert invalid UTF-8 that was dragged into entries.
When you drag that ö from mozilla to gtk, selection_get_text_plain() in gtkselection.c calls g_convert_with_fallback("\xc3\xb6", "ISO-8859-1", "UTF-8") which returns "\xf6" which is not valid UTF-8. So it's a glib bug (or glibc?).
Nevermind, the real problem was apparently copy/paste. Fix: Index: gtk/gtkselection.c =================================================================== --- gtk/gtkselection.c (revision 17599) +++ gtk/gtkselection.c (working copy) @@ -1310,7 +1310,7 @@ selection_get_text_plain (GtkSelectionDa { gchar *tmp = str; str = g_convert_with_fallback (tmp, len, - charset, "UTF-8", + "UTF-8", charset, NULL, NULL, &len, &error); g_free (tmp);
(In reply to comment #7) > Nevermind, the real problem was apparently copy/paste. Fix: > > Index: gtk/gtkselection.c > =================================================================== > --- gtk/gtkselection.c (revision 17599) > +++ gtk/gtkselection.c (working copy) > @@ -1310,7 +1310,7 @@ selection_get_text_plain (GtkSelectionDa > { > gchar *tmp = str; > str = g_convert_with_fallback (tmp, len, > - charset, "UTF-8", > + "UTF-8", charset, > NULL, NULL, &len, &error); > g_free (tmp); patch looks fine, please apply+test+commit with appropriate changelog.
Committed (I can't close this bug). There is another bug: when you drag that Bjoern to a gtk entry, it inserts some nonsense instead of fancy o with dots. But that's a different problem, about what text/plain is supposed to contain and how to treat it.
I hesitate to close this bug before that other bug is opened.
See #429738.
So, what's the mozilla bug about it not offering UTF8_STRING, which is the *only* target that I'm aware of that actually is well defined as to encoding?
These are relevant: https://bugzilla.mozilla.org/show_bug.cgi?id=179658 https://bugzilla.mozilla.org/show_bug.cgi?id=40608