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)
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: kazhik, Assigned: masaki.katakai)
References
Details
(Keywords: intl, Whiteboard: need pavlov to review.)
Attachments
(3 files)
1.88 KB,
patch
|
Details | Diff | Splinter Review | |
1.41 KB,
patch
|
Details | Diff | Splinter Review | |
1.44 KB,
patch
|
Details | Diff | Splinter Review |
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
Comment 1•24 years ago
|
||
Reassign to ftang. IQA, can you reproduce this?
Comment 2•24 years ago
|
||
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.
Comment 3•24 years ago
|
||
Xianglan and I tested this on Linux. We could reproduce this. I confirm this bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•24 years ago
|
||
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)); }
Comment 6•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
Comment 8•24 years ago
|
||
Toshi, would you like to own this?
Comment 9•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
reassign to bstell and cc shanjian. Mark it as P3 moz0.9
Comment 12•24 years ago
|
||
Pavlov, do you work on X copy-n-paste?
Comment 13•24 years ago
|
||
yes
Comment 14•23 years ago
|
||
pavlov- can you code review this patch ?
Updated•23 years ago
|
Target Milestone: mozilla0.9 → mozilla0.9.1
Updated•23 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Reporter | ||
Comment 16•23 years ago
|
||
*** Bug 81933 has been marked as a duplicate of this bug. ***
Comment 17•23 years ago
|
||
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.
Updated•23 years ago
|
Status: NEW → ASSIGNED
Comment 18•23 years ago
|
||
r=ftang
Comment 21•23 years ago
|
||
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?
Comment 22•23 years ago
|
||
katakai@japan.sun.com Can you address the issue kin raise?
Status: NEW → ASSIGNED
Comment 23•23 years ago
|
||
a good site for Xlib info: http://tronche.com/gui/x/xlib/function-index.html
Assignee | ||
Comment 24•23 years ago
|
||
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.
Comment 25•23 years ago
|
||
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
Assignee | ||
Comment 26•23 years ago
|
||
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?
Assignee | ||
Comment 27•23 years ago
|
||
Comment 28•23 years ago
|
||
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.
Assignee | ||
Comment 29•23 years ago
|
||
Comment 30•23 years ago
|
||
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Blocks: 83989
Assignee | ||
Comment 31•23 years ago
|
||
patch checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•