Apache OpenOffice (AOO) Bugzilla – Issue 28193
Copy and Paste between OOo and KDE applications can fail.
Last modified: 2004-10-20 13:32:21 UTC
In version up through 1.0.1 I could freely copy text to and from OOo to any other application on the KDE desktop. Without any changes to my desktop software beyond adding Language Support for German and upgrades to OOo, I have noticed the following: Version 1.1.0: Copy and Paste FROM OOo to any KDE application truncated text beyond five or six paragraphs. TO OOo works fine. The amount of text that could be copied FROM OOo did not seem to change with multiple copies. Version 1.1.1: Copy and Paste FROM OOo to any KDE application truncated text after one to two paragraphs. TO OOo works fine. The amount of text that could be copied FROM OOo continued to drop until I closed and restarted OOo Version 1.1.2rc: Copy and Paste FROM OOo to any KDE application truncates at the first line break or on the fifth or sixth line of a paragraph or somewhere else within that range. TO OOo works fine. The amount of text that could be copied FROM OOo now continues to drop until I close the application AND the desktop and relog in and restart OOo. In some cases, it copies not what I marked, but some additional text that I had marked some time earlier. Result: OOo 1.1.2rc is completely unusable for me. I work on a collaberative project that requires copying and pasting to email for work on sections rarely larger than a few paragraphs. This degeneration in copy and paste performance as new versions has come out has destroyed the usefulness of the program for me entirely as this is how I make my income (I am home-bound under medical treatment). In the past, when something of this sort has been mentioned, it has been dismissed as due to some other cause, but in this case, no basic programs have been changed and the degeneration has become virtually complete. As some help, I have noticed that if I wait for five to ten minutes before pasting, I can sometimes copy an extra line or a half line. However, when I do that, the extra (unselected) text always appears. Something is seriously wrong either with OOo's internal "copy and paste" cache (if you have something like that) or with integration into the KDE desktop's Klipper and it has gotten worse each time a new upgrade has come out. BTW, I've reverted to 1.1.0 so I can actually get some productive work accomplished. This cuts me off from enhancements in saving and reading Word Docs, but it is far better than a useless cut and paste function.
changing subcomponent, leaving P", as this is basic functionality not working. *but* I cannot reproduce this (unfortunately this issue was filed as "NEW") maybe an important note from the mailinglist: This happens on a KDE 2.2.2 environment. I'm asking at dev@qa and dev@kde for help.
We have another duplicate report from someone using SuSE 8.2. I have no idea what version of KDE is used, but we should know within a day or two if the problem is unique to KDE 2.2.2. Just seems to me we should drop support for Windows 98 as it is older than KDE 2.2.2 -- just kidding!
i can reproduce this sort of thing quite easily (but only semi-repeatably) on my setup: Suse 8.2 KDE 3.1.1 OOo 1.1.1 i have klipper disabled by default on my desktop. with no klipper running, i opened up a konsole window, started a vi session on an empty file, and entered insert mode. i then highlighted a big chunk of text (> 1025 chars) in an OOo text document and clicked the middle mouse button on the vi session. no matter how much text was highlighted, only 1025 characters appeared in the vi window. did not seem to matter how many or few paragraphs, the 1025 char limit seemed constant. i tried clicking Ctrl-C to copy first, and it did not make any noticable difference. i then started klipper. i didn't keep detailed notes, but it had varied success in pasting chunks of text. at this point, however, the 1025 char limit changed. anywhere from a few tens of chars, up to more or less all of the highlighted text appeared in the konsole. i then quit klipper, and now it seems that my cut and paste works pretty good. everything i highlight seems to get copied just fine into the vi session in konsole. i notice performance is not great, however: a paste of 51673 chars from OOo takes about 3 seconds to register with the system, and then just under 35 seconds of pegged CPU, 25% system, 75% user, with my hard drive going nuts all the while. the konsole process is the one hogging the CPU. finally, the paste completes and the chars appear in the konsole. this problem is not limited to konsole and vi, i have also seen it when pasting documents from OOo into form fields in Opera 7.11 and 7.50. (Probably other apps as well, but nothing else is jumping to mind at the moment.) Opera seems to have a bit worse time of it. i haven't broken the 1025 char limit in a few minutes of testing, but after starting klipper, the paste dropped to a small number of chars (< 10) and sometimes the paste just inserts random chars into, for example, the textarea in a slashdot reply form. not sure what else to report.... anyway, something is very definitely wonked wrt. clipboard cut and paste in current kde/openoffice combos. hope it helps
JA->Robert: AFAIK the clipboard implementation of KDE 2 had a bug which prefered X selection over the clipboard application content. This bug disappeared in KDE 3. I would suggest to update KDE on your system. My opinion is that this isn't a bug within OpenOffice.org but within that KDE version. I CC pl@openoffice.org who might give us a more detailed opinion about this topic. For further communication I would suggest to think about what "X selection" is and what "Clipboard" is Please read the paragraph beginning in line 26 (mentioning the broken behavior...): http://developer.kde.org/documentation/library/cvs-api/kdecore/html/kclipboard_8cpp-source.html
confirmed, happens with kate as well as konsole, no problems with emacs or kvim.
starting
I will try with klipper off as well as on and see what happens. I notice that there has been degeneration, however, as it worked fine with 1.0.1 using the same KDE version. I still feel that such degeneration should not have occurred, but I will check.
Klipper off. No copy to text editor, nor to anything else when using "Ctrl-C" and "Ctrl-V". Works with "Ctrl-C" and right-click then select paste. Works with "Copy" (in OOo) and Middle-click in other application. Copied text begins to degernate after a time, but not as drastically as previously reported. Then turned klipper on and all copies seemed to work well. No degeneration unti the tenth copy-and-paste. The question remains: if this is a KDE2.2.2 problem, why did it not exist in 1.0.1 and began to degenerate from 1.1.0 onward? So far, all I have seen is "you have encountered a KDE 2.x bug." But it didn't exist in 1.0.1. Suddenly KDE has a bug that not only appears but gets worse with each update in OOo. And only OOo. All other updated applications (Opera and Mozilla, for example) continue to function flawlessly. In any case, sometime next month I expect to upgrade to KDE 3.2.x (whatever is current) so I'll see if that fixes the problem.
It will fix the problem that KDE confuses clipboard and primary selection. It will not fix the problems with some KDE applications.
What went wrong: - KDE applications sometimes fail to properly act on INCR protocol (incremental transfers) - this is used to break up large data transfers into smaller blocks. OOo had a rather restrictive view of what constitutes a "large" data transfer, namely 1024 bytes. - In OOo's clipboard code a failed INCR transfer would interfere with a second try, resulting in even more garbage. - Mozilla does not grog incremental transfers at all What i did: - fixed the problem with failed old transfers interfering with next tries - increased the threshold for incremental transfers to reasonable amount: the maximum request size of the display connection minus 1k ; this also increases performance dramatically as far less roundtrips are necessary to transfer the data Still remaining: - kate/kwrite sometimes fail to get the data in an incremental transfer, which will result in garbage - this is a KDE/Qt bug IMHO. At least this will happen only with much larger clipboard contents now. Also a second try usually results in a correct data transfer. - kate/kwrite crash on huge clipboard contents; this is clearly a KDE bug since this happens long after the data transfer has finished. - Mozilla does not paste incremental transfers at all; this happens now with much larger clipboard contents than before. As far as i can see this is what can be done on OOo's side to solve the clipboard situation. Fixed in CWS vcl22
utomo > pl: Please consider to include this fix in 1.1.x series. as this is important regresssion in Linux. and the fix already available (vcl22). Thanks. Note: I use win xp, so I did not feel as bad as rblackeagle
target is not mine to decide; ja: what's QA's opinion on this ?
JA: I wouldn't like to put this fix into the srx645 (1.1.2) branch. From my point of view it's too late to put it into 1.1.2. Such fixes in vcl within a stable branch are too risky to be implemented.
SBA: After talking to PL, US and JA, I have submitted issue 29087 as a clone of this one in order to get the fix into OOo 1.1.3. I'd like Robert to have a look for possible side effects as soon as THIS fix got integrated into a 680 Build with CWS vcl22.
Utomo > SBA: Thanks. But http://www.openoffice.org/issues/show_bug.cgi?id=29087 Search by issue number There does not seem to be an issue numbered 29087 BTW: Stefan, have you receive my email? I did not got the reply yet.
OK, I create Issue 29166 for this clone. Thanks
JA: Stefan created a clone with issue ID 29078
Thanks. It because issue 29078 and issue 29087 :)
reopen for reassign
reassign
pl->ja: please verify in CWS vcl22
JA: tested & verified KDE clipboard exchange from SO/OOo -> Mozilla Composer in CWS vcl22
JA: closing issue