Issue 62588 - Pasting from clipboard pastes wrong content
Summary: Pasting from clipboard pastes wrong content
Alias: None
Product: Writer
Classification: Application
Component: editing (show other issues)
Version: OOo 2.0.3
Hardware: PC Linux, all
: P3 Trivial (vote)
Target Milestone: ---
Assignee: AOO issues mailing list
QA Contact:
Keywords: oooqa
Depends on:
Reported: 2006-02-26 13:18 UTC by mkoller
Modified: 2013-08-07 14:38 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description mkoller 2006-02-26 13:18:43 UTC
When pasting text which I copied into the clipboard from the KDE konqueror 
application, in writer I see a wrong text appearing.
It seems to happen only when I paste text from a HTML page.
E.g. When I have the following page displayed

       Test Text 123

and I mark the "123" part, press CTRL-C, and paste with CTRL-V into writer, 
the text which appears is "t T"

Interesting is: When I create a new calc document, and do CTRL-V in a cell 
(without having the input cursor), also "t T" appears, but when I triple click 
the cell so that I see the input cursor and do then CTRL-V, the correct text 
"123" appears!
Comment 1 michael.ruess 2006-02-27 07:26:19 UTC
Reassigned to ES.
Comment 2 eric.savary 2006-02-27 15:56:00 UTC
I cannot reproduce it.
KDE 3.2.1/SuSE 9.3.
Please test this with a newer version a try this with other browsers.

Comment 3 mkoller 2006-02-28 07:36:37 UTC
I'm using KDE 3.5.1 and I got the report of the problem from someone working 
with Suse 9.3/KDE-3.5

I tried with firefox but can not reproduce it with it.
But as the pasted text works everywhere in KDE, it must be an issue with OO.

I think it might have to do with the fact that probably konqueror puts the 
text as text/html in the clipboard, but in the described case writer extracts 
the html text as plain text or something ...

Another thing which might help to find the bug: When the clipboard contains 
text with some german umlauts, the pasted text not only shows the wrong part, 
but it also shows the UTF-8 characters (I mean 2 chars instead of the 1 
Umlaut); e.g. the following HTML page:
        Umlaut fuer f&uuml;r xxxxx yyyy zzzz
Now copy (by click-move-release) the full line, and paste it (CTRL-V) into 
I get:
 Umlaut fuer für xxxxx y
You can see both effects: Umlaut U shows as 2 characters, and the last few 
chars are not included.
Comment 4 Joost Andrae 2006-03-25 22:48:28 UTC
Maybe you didn't feed the X clipboard but did a X selection. Both can contain
different content.
Comment 5 eric.savary 2006-09-22 09:22:16 UTC
No answer
Comment 6 eric.savary 2006-09-22 09:22:33 UTC
Comment 7 mkoller 2006-09-22 10:04:28 UTC
What answer did you expect ?
I think I described in all details what I did.
I can still reproduce it with OpenOffice 2.0.3 and KDE-3.5.4 on a Suse-9.3

Use my given HTML testpage, select the full line, CTRL-C, CTRL-V in writer and 
the result is "Umlaut fuer für xxxxx y" which is not the full line.

Using the X-clipboard (pasting with middle mouse) shows correctly the full 
Comment 8 Rainer Bielefeld 2006-12-05 14:36:44 UTC
Please attach a .html testfile, a file with the pasted result and your clipboard
Comment 9 mkoller 2006-12-17 15:09:22 UTC
To rainerbielefeld:
Have you really read my original bug report ?
Please have a look at my very first explanation, there you find a HTML example 
(7 lines) and an exact description of what I did and what I get.
It really does not help you any further if I attach again and again the same 

BTW: I now tested this with Suse 9.3, KDE-3.5.5 and the latest OpenOffice 2.1 
(german version) and I still can reproduce the problem.
Comment 10 Rainer Bielefeld 2006-12-17 17:59:42 UTC
Reporter is not willing to contribute the required sample files, so I close this
issue due to 'Additional comments from es Mon Feb 27 07:56:00 -0800 2006'

Pls. feel free to reopen the issue when you can contribute requested information.
Comment 11 eric.savary 2006-12-20 01:49:16 UTC
Well now testing with SuSE 10.1 and KDE 3.5.1 I could reproduce it.
It only affect the HTML clipboard. Only in combination with Konqueror.
Srange thing!
Comment 12 eric.savary 2006-12-20 01:50:31 UTC
ES->AMA: please have a look.
Comment 13 maruthapillai 2007-01-25 20:30:47 UTC
We were UNABLE to reproduce this issue on OOo 2.0.3 running
on the following configurations separately:

One Intel(R) Pentium(R) 4 CPU 2.80GHz with 1GB RAM running -
1. Linux 2.6.9-42.0.3.EL.CSE.smp #1 SMP i686 i686 i386 GNU/Linux
2. MS Windows XP Pro Ver. 2002 (SP2)

However, we did two follow up tests with the same HTML page
(containing graphics and text) copied from three different
browsers. Follow the steps below:

1. Open OOo
2. Open a temporary text document or create a new one
   via File->New->Text Document...
3. Open Mozilla (mine was SeaMonkey 1.1)
4. Open FireFox  (mine was
5. Open Konqueror (mine was 3.2.1 using KDE 3.2.1)
6. Point all the browsers to any webpage containing
   graphics and images for eg.
7. Mark/Select/Highlight a block/portion of text and
   images on each browser page in turn. From each
   browser Edit menu select the Copy option ie.
   Edit->Copy or alternative use Ctrl-C.
8. Now right click and paste on the OO Text document

It will be seen that the portion copied from the Mozilla
and Firefox browsers preserver the the images and some
of the structure of the highlighted portion. But with
Konqueror, the images do not show up and the structure
of the pasted portion is lost if the there were tables
in the original webpage.

The point of doing this follow up test is to check if
this behavior is due to browser issues. From the 
above result, it seems that the this issue could be
a defect with Konqueror's Copy function rather than
OOo. It seems only text is being copied to the clipboard
from Konqueror.
Comment 14 maruthapillai 2007-01-31 22:20:04 UTC
Addendum to my comments under:
"-- Additional comments from maruthapillai Thu Jan 25 12:30:47 -0800 2007 --"

The earlier followup tests were performed on:
(1. Linux 2.6.9-42.0.3.EL.CSE.smp #1 SMP i686 i686 i386 GNU/Linux)
as previously stated.

(For 2. MS Windows XP Pro Ver. 2002 (SP2)), the Konqueror browser
software was not installed in the lab servers. Hence, we only used the 
following browsers:
1. Mozilla SeaMonkey 1.0.4
2. Firefox
3. Internet Explorer 6.0.2SP2

We got the same results as with Mozilla SeaMonkey and FireFox on Linux.