Closed Bug 56936 Opened 24 years ago Closed 23 years ago

Can't copy Japanese string from emacs by mouse

Categories

(Core :: Internationalization, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: kazhik, Assigned: masaki.katakai)

References

Details

(Keywords: intl, Whiteboard: need pavlov to review.)

Attachments

(3 files)

Copy Japanese string from emacs to Mozilla's text field fails.

(1) Select Japanese string on emacs
(2) Paste it on Mozilla's text field by mouse. The string is
converted incorrectly.

This problem was reported on Japanese bugzilla.
http://bugzilla.mozilla.gr.jp/show_bug.cgi?id=349
Reassign to ftang.
IQA, can you reproduce this?
The selection data "B$"$$$&$($*" given by xemacs in the example
looks wrong, in that it is encoded in japanese JIS and the data format is 32.
(I guess so from the fact that the byte order of the data is little endian.)

Since it is given as COMPOUND_TEXT encoding to selection receiver, it should be
convertible with XmbTextPropertyToTextList function call, setting
textProp.format=8,
textProp.encoding=COMPOUND_TEXT.

Xianglan and I tested this on Linux.  We could reproduce this.  I confirm this bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
I made a patch.
I verified the fix only with FSF/Emacs20.7.
This fix is almost a workaround, which is also done by GTK+[gdk/gdkselection.c].


--- widget/src/gtk/nsClipboard.cpp.orig Thu Sep 14 08:55:28 2000
+++ widget/src/gtk/nsClipboard.cpp      Thu Oct 19 00:35:26 2000
@@ -555,7 +555,12 @@
 
     PRInt32 numberOfBytes = 0;
 
-    if (status == Success) {
+    if (status == XNoMemory || status == XLocaleNotSupported ||
+        status == XConverterNotFound) {
+      g_print("\n         XmbTextListToTextProperty failed.  returned %d\n",
status);
+      g_print("          text is \"%s\"\n", tmpData[0]);
+      numberOfBytes = nsCRT::strlen(NS_REINTERPRET_CAST(const char *, data));
+    } else {
       data = tmpData[0];
       numberOfBytes = nsCRT::strlen(NS_REINTERPRET_CAST(const char *, data));
 
@@ -564,10 +569,6 @@
       g_print("          text is \"%s\"\n", data);
       g_print("          numberOfBytes is %d\n", numberOfBytes);
 #endif
-    } else {
-      g_print("\n         XmbTextListToTextProperty failed.  returned %d\n",
status);
-      g_print("          text is \"%s\"\n", tmpData[0]);
-      numberOfBytes = nsCRT::strlen(NS_REINTERPRET_CAST(const char *, data));
     }
Erik, could you take care this?
Assignee: nhotta → erik
Inoue-san's patch may be a good workaround for xfree86/linux.
I want to add an error check to prevent accessing null text.
Attaching a new patch.



Toshi, would you like to own this?
Erik, can you keep owing please? I don't hit better solution than inoue-san'
workaround, but the patch would be better to check in, if it resolves
the problem in xfree86/linux.


Keywords: intl
Changed QA contact to ylong@netscape.com.
QA Contact: teruko → ylong
reassign to bstell and cc shanjian. Mark it as P3 moz0.9
Assignee: erik → bstell
Keywords: patch
Target Milestone: --- → mozilla0.9
Pavlov, do you work on X copy-n-paste?
yes
pavlov- can you code review this patch ?
Target Milestone: mozilla0.9 → mozilla0.9.1
adding nsbeta1 keyword. let's get it in . . .
Keywords: nsbeta1
Target Milestone: mozilla0.9.1 → mozilla0.9.2
*** Bug 81933 has been marked as a duplicate of this bug. ***
  I tested the patch (attachment) on FreeBSD/XFree86 and Mule-2.3.
I found the problem if this patch is not applied, and I cannot find
the problem if this patch is applied.

Status: NEW → ASSIGNED
r=ftang
reassign to ftang
Assignee: bstell → ftang
Status: ASSIGNED → NEW
pavlov- can you review this one ?
Whiteboard: need pavlov to review.
Ok I have several questions regarding the 10/18/00 11:16 patch
since I'm not familiar with the gtk clipboard implementation and don't
have any Xmb documentation in front of me:

1. After we execute the following line:

      char *data = (char*)aSD->data;

   we never check to see if data == null, are we guaranteed
   that data will never be null? Or does that not matter?

2. We never check to see if tmpData is null before we
   dereference it with tmpData[0]. Does XmbTextPropertyToTextList()
   guarantee that tmpData will never be null?

3. Are we sure that XNoMemory, XLocaleNotSupported and
   XConverterNotFound are the only real ERRORS we need to catch
   to flag as FAILED?

   The patch seems to indicate that this is the case. What
   is the value of status if it's not "Success" or one of the
   errors mentioned above? That is what is the status you
   are seeing in the specific case that you are trying to fix?
   And is it valid to assume that tmpData[0] is something
   you can use if status != Success?

katakai@japan.sun.com
Can you address the issue kin raise?
Status: NEW → ASSIGNED
1. I've checked gtk+ codes and I understand aSD->data is set to NULL when
   aSD->length <= 0, that check is called at top of nsClipboard::SelectionReceiver()

2. It's OK when XmbTextPropertyToTextList() reuturs Success. But sorry, I'm not
sure,
   I could not find any description that tmpData is always valid when whole
   characters are not converted (when it returns "number of unconvertible
characters").
   But I also could not find any description tmpData is set to NULL...

3. XmbTextPropertyToTextList() returns XNoMemory, XLocaleNotSupported,
   XConverterNotFound, Success and otherwise returns
   "number of unconvertible characters". At the case, tmpData can
   contain converted characters.

katakai- can you change the current patch to be more defensive (check the null 
again) and resubmit a patch ?

Reassign to katakai 
Assignee: ftang → katakai
Status: ASSIGNED → NEW
For issue 2, I have discussed with Hidetosh.Tajima@Sun.COM and
we agree that we should check 'foo' first then look tmpData.
In the case when XmbTextPropertyToTextList() doesn't return
error codes, foo is a number of text strings of tmpData,
so foo > 0 means something is tmpData, then we can check it.

    if (status == XNoMemory || status == XLocaleNotSupported ||
        status == XConverterNotFound) {
      g_print("\n         XmbTextListToTextProperty failed.  returned %d\n",
status);
      g_print("          text is \"%s\"\n", tmpData[0]);
      numberOfBytes = nsCRT::strlen(NS_REINTERPRET_CAST(const char *, data));
    } else {
      if (foo > 0 && tmpData[0] != 0 && (*tmpData[0]) != 0) {
        data = tmpData[0];
      }

I'll attach revised patch. Pavlov, can you review the patch?
Please put this:

+      g_print("\n         XmbTextListToTextProperty failed.  returned %d\n",
status);
+      g_print("          text is \"%s\"\n", tmpData[0]);

into an #ifdef DEBUG_CLIPBOARD.

Do that and you have an sr=blizzard.
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
patch checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Fixed verified on 0.9.2 Branch build(06-25).
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: