Issue 49907 - Time delay when using copy/paste/cut when a clipboard viewer is running
Summary: Time delay when using copy/paste/cut when a clipboard viewer is running
Alias: None
Product: General
Classification: Code
Component: code (show other issues)
Version: current
Hardware: All All
: P3 Trivial with 36 votes (vote)
Target Milestone: AOO Later
Assignee: AOO issues mailing list
QA Contact:
: 75488 112682 (view as issue list)
Depends on:
Reported: 2005-05-26 13:10 UTC by wolframgarten
Modified: 2017-05-20 10:45 UTC (History)
14 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 wolframgarten 2005-05-26 13:10:28 UTC
This issue is not reproducible by myself but I have seen it on NP's machine
where it is reproducible. 
When using one of the clipboard functions on a textobject there is a time delay
of several seconds before any further action can be done. According to NP this
was already occuring in the beta.
Comment 1 johanpirlouit 2008-04-09 02:49:59 UTC

This issue doesn't seem to be reserved to OOo Drawing, it is the same with OOo

It can be reproduced with any OOo 2.x, up to current 2.4 release and running
under Windows (I can see it with 2000 and XP; I don't use Vista).

As I can see with Writer, the delay is about 5 to 6 seconds, which can be really

Example to reproduce this issue:
- type any text or open any text file in OOo Writer (even ODT files)
- select any text
- copy selected text (CTRL-C)
- paste it wherever you want, for example any simple or advanced text editor
(such as MS Notepad or Notepad++) or any web browser (paste into any form text
input) or any other app.

By the way, this delay doesn't seem to be present running OOo under Linux (I
don't see this issue with OOo Writer 2.3 on my Kubuntu 7.10).


Comment 2 harveyab 2008-04-23 00:47:41 UTC
The copy delay problem occurs on both my Win 98 desktop and my Win XP Dell 1150
notebook. I am running OOo Ver 2.3.1 on both. Older versions also did the same
on my Win 98 machine.

I use ReadPlease 2003 a lot for reading to me and the delay is very annoying.
The delay can be as long as 8 seconds. With other apps, ReadPlease is triggered
immediately upon ctrl-C (I don't have to do a paste).

Harvey Block
Comment 3 harveyab 2008-04-23 00:52:58 UTC
Oh, I intended my comments to be related to Writer. They most likely apply here
but I have not tried the drawing package yet. I will try to post there as well
and ref this one.

Harvey Block
Comment 4 phil_ 2008-05-14 09:11:43 UTC
I cannot reproduce this on my system (OOo 2.4.0 on Win XP Pro SP 2).
However, there seem to be more people encountering it as shows <a
thread</a> on OUCV.

Also, I think <a href="show_bug.cgi?id=75488">issue 75488</a> could be related
to this one (or even be a duplicate).
Comment 5 harveyab 2008-09-06 08:02:16 UTC
As for my copy delay issue with Writer, I suspect the problem is at least partly
in ReadPlease. If I load ReadPlease before Writer, then the delay is there, but
if I load Writer first then there is no delay. (ReadPlease caused Word79 to
crash - one of my main reasons for getting interested in OOo Writer in the first
place, and I'm glad I did!
Comment 6 korin43 2009-03-25 20:13:34 UTC
I have this issue as well in Writer version 3.0.1 (and I remember it happening
in previous versions as well) on Windows XP.

I just wanted to add that this problem does not occur when dragging text from
OpenOffice into another program.
Comment 7 fullmetal 2009-04-13 05:30:32 UTC
Same thing in OOo 3.0.1
This is not antivirus or something and i dont use any clipboard soft.
This 4 second delay is killing me.
Comment 8 leokom 2009-04-21 21:28:09 UTC
The issue is easily reproducible at my working and home PC's with WinXP SP3 + 
OpenOffice 3.0.1.
It's very annoying, and it existed in previous versions as well.
Comment 9 loony 2009-05-07 19:47:51 UTC
I experience the same issue, here is some data:

System: Kubuntu Jaunty 9.04
Graphics controller: Intel Corporation Mobile 945GME Express
Processor: Intel Atom N270 @ 1.60 GHz (512 Kb cache)
Ram: 1Gb

Steps to reproduce:
1. Open Writer
2. Open another application (gtk preferred) like Firefox
3. Copy some text in a document opened in writer
4. Switch to Firefox *with the mouse through taskbar*
5. There will be a delay from 3 to 5 seconds
6. Try to paste the contents of the clipboard

- *Sometimes* the copied text is not in the clipboard
- When using the taskbar to switch there will be a delay

Expected results:
- Don't detain task switching with *mouse*
- Copy the selected text to clipboard everytime

I cannot reproduce this problem on every system, but on some (OO version 3.0 and
3.1). Switching the task with the mouse (background window) does not result in
the delay.

Comment 10 hawkwing3141 2009-05-31 02:17:06 UTC
loony has described my observations exactly.

System: Kubuntu Jaunty 9.04
Graphics controller: ATI Technologies Inc Radeon RV200 QW [Radeon 7500]
Processor: Intel Pentium 4 @ 1.8GHz
Ram: 2Gb
OOo: 1:3.0.1-9ubuntu3
pause between window switching after copy: 4 seconds
Comment 11 aliq 2010-01-26 13:17:04 UTC
I've got following situation: I open OOo and then am having 10-seconds-delays
when try to paste something from OOo to another program (this issue subject). 
I've got a program - Punto Switcher - which resides in background and doing some
changes with currently selected text. I think it uses clipboard, because it's
operations in OOo have those delays too. Also that program has function of
clipboard monitoring: it remembers 10 last copied strings.
So, when I exit (and re-open) that program - the problem disapears.
I've had same situation abuot three years ago with NetBeans. 
I hope this info will help.
Comment 12 loony 2010-01-26 14:06:57 UTC
When I experiences the problem I used to have klipper (a kde clipboard app)
active in the system tray. Since I am using Gnome at the moment I don't see
these problems anymore. I will make some more tests with and without clipboard
programs active and report back.
Comment 13 the_ant 2010-05-29 20:26:59 UTC
This is still happening on OO version 3.2 (just installed) and has been
happening since around version 2.2 or 2.4 (I can't remember exactly when it
started to happen). It is very uncomfortable for the end user and should be
fixed as soon as possible. It might also lead to the user dropping Open Office
due to this (I personally do not use it as often as I could just because of this
I had it happen on both Writer and Calc. A fresh install with a clean profile
does not solve the problem.
Comment 14 clippka 2010-06-10 15:05:47 UTC
since this is a framework issue as it affects all ooo application I'm the wrong

@cl->mba: please reassign as you see fit
Comment 15 rewraziel 2010-06-22 23:33:37 UTC
For users on Windows:

The workaround is simple, yet not very obvious.
1. Make sure no clipboard viewing program is running.
2. Open Writer, write "OpenOffice hates clipboard viewers", copy it to clipboard
(CTRL+C or context menu).
3. Now you can run any clipboard viewing software without those nasty delays.

Strange that it hasn't been fixed a long long long time ago.
Comment 16 eric.savary 2010-06-25 11:58:24 UTC
*** Issue 112682 has been marked as a duplicate of this issue. ***
Comment 17 eric.savary 2010-06-25 12:15:29 UTC
*** Issue 75488 has been marked as a duplicate of this issue. ***
Comment 18 eric.savary 2010-06-25 12:16:33 UTC
Re-adjusting component and summary.
Comment 19 eric.savary 2010-06-25 12:17:24 UTC
@MBA: the comments in the duplicate issue 75488 might also help.
Comment 20 the_ant 2010-06-25 12:19:39 UTC
This happens even if no clipboard viewer is in use. I have no software to view
the clipboard contents and it happens just the same.
Comment 21 pcullum 2010-06-25 13:14:07 UTC
Is this not the same problem as bug 18380.  It's status is STARTED.... that was
in 2003.
Comment 22 rewraziel 2010-06-25 15:37:54 UTC
"the_ant: This happens even if no clipboard viewer is in use. I have no software
to view
the clipboard contents and it happens just the same."

Lol :) I'm not talking about a program which lets you see the contents of the
clipboard... I'm talking about programs that ARE clipboard viewers, a program
which calls the MS API function called SetClipboardViewer().
Any program can become a clipboard viewer, a misleading name from MS.

They don't have to show you anything from the clipboard. The fact that they are
clipboard viewers is what's messing OOo up.

A lot of programs watch the clipboard queue without letting the user know. They
may use it for primitive interproc communication. The older the program the more
likely it is a clipboard viewer.

Let's get rid of this bug already.
Comment 23 john_ha 2010-08-03 10:58:51 UTC
I have raised a bug report "OO does not paste the text contents of the Windows
clipboard - instead, it pastes the previous text copied in OO" at where my debugging found
this delay with a clipboard viewer.

In my case, OO immediately clears the previous contents of the clipboard, but
takes several seconds to put the new contents onto the clipboard.

Is my original problem, that "OO does not paste the text contents of the Windows
clipboard - instead, it pastes the previous text copied in OO" related to this
time delay problem?
Comment 24 rewraziel 2010-08-10 09:05:58 UTC
john_ha: yes, any delay noticed when using a clipboard viewer relates to this
Comment 25 friendfx 2010-10-05 06:17:51 UTC
Yet another link to a forum thread with this topic... a VERY OLD one!
Comment 26 gibbonsd1 2010-12-05 23:12:24 UTC
I'm using OpenOffice 3.2.1 Impress on Windows 7 and whenever I copy or cut, it 
takes 2-3 seconds. Paste doesn't have an issue. I don't run an anti-virus.
Comment 27 josarek 2011-01-11 08:55:05 UTC
I have the same problem in OOO Applications. E.g. in OOO Impress it freezes the
whole application about 5 seconds to copy or cut a text with ctrl+c or ctrl+x
while a delete of the text works immediately. A copy and paste in other
applications such as text editors works fine and immediately.

Please find the cause of this issue and remove it. Thank you.
Comment 28 andrey 2011-07-16 12:38:41 UTC
The same problem in Macro editor for Lotus Symphony. Using Ditto clipboard manager.
Comment 29 aks 2012-09-26 16:33:40 UTC
This bug has been around for 7 years and is still not fixed? I've had to stop using a variety of programs because of it and it's often hard to track down exactly what program is viewing the clipboard. After installing some new hardware and accompanying software, the bug is back and I'm not sure if I can disable whatever is causing it without losing the function of the hardware. OOO is completely unusable with this bug, please fix it.
Comment 30 Tone 2012-10-19 19:52:41 UTC
I found something interesting.

If I run OO Write via an UltraVNC remote connection, I get the 4 second delay when I hit CTRL-C for copy. That seems consistent with what the others have been saying.

** However **

If I go to the physical machine itself and hit CTRL-C from the physical keyboard, I don't get the problem at all. I didn't shut down the UltraVNC connection from the remote machine, nor did I restart the running instance of OO Writer.

The bottom line: I can't use UltraVNC to remote-in to my server box and run OO Writer or I get that nasty delay.

I'm running . . . 
Version: 3.4.1
OS: Windows 2008 Server Standard
Comment 31 Len Hodder 2013-10-29 17:56:32 UTC
I have had the same problem, and base on the last comment, I have discovered that if UltraVNC is open, even if minimized, the copy will be slow, and the hard disk will thrash for the 5 seconds or so.  The paste is instantaneous.  UltraVNC has the ability to cut-and-paste across PCs, so a copy on my PC (where OO is open) can be pasted to a document in the UltraVNC remote desktop window, and appear in a document on the other PC.  Maybe it's related to that - the need to copy the clipboard to a file (or wherever) to use for the remote PC paste operation.  If I close any open UltraVNC windows, the copy and paste is instantaneous.

Hope this helps in some way.
Comment 32 eehernandez 2014-06-19 16:51:27 UTC
Problem still present on OO 4.1.0 on Windows XP
Comment 33 dma_k 2014-07-23 22:42:47 UTC
I experience the same problem with OOO Calc (as well as LibreOffice Calc): I hit Ctrl-C in Calc and the content becomes available in another application after 2-3 seconds (I press Ctrl-V periodically until it is inserted). The waiting time seems to be proportional to the content being inserted (the more you select the longer you wait). I am not running any clipboard viewer. I have tested on two different PCs with different anti-virus software – so it is not related to problem. I have Intel Core i7 – I think this CPU should be OK to paste few cells from one app to another quickly.
Comment 34 Shonzie 2014-10-22 18:41:57 UTC
I have the same problem here with Apache Open Office Calc 4.1.1!!!

The copy command takes several seconds (5-10 or more) until something happens.

I worked with Open Office Writer 3.x very intensive times ago and can not remember a similar problem. I know, this is not a neat comparison, cause I never used Calc before more deeply.

It looks like there is some routine in the program circling around or waiting for some event that does not happen...

Please someone try to find the error and fix it, this is really a shame-bug and absolutely no-go.
I will deinstall Calc as soon as I have found out how to port my data to an alternative app.
Comment 35 subnoodle 2015-01-12 20:37:15 UTC
Hello alltogether,

the clipboard copy delay of ooo is very common to me, for at least 2,5 years on different windows-plattforms and hardware-plattforms.

I also strongly whish to get this solved.

A) Copying from ooo to another application or itself causes always a ~20 - ~30"-delay.

B) Additional hanging of ooo

Appears very mostly, nearly always; depends maybe on Skype or Teamview or Mouse without borders or one of the other many clipboard managing applications.

One sucess was to exit skype completely, copy something from ooo and restart skype. Delay-free coping persistet in spite running skype.

Thank you for all your great work!!!

Comment 36 Marcus 2017-05-20 10:45:12 UTC
Reset the assignee to the default "".