Reassigning to "core" for evaluation.

I don't know if we'll be able to do anything here, but just in case I'm ccing
guys  who knows something about clipboard policy in NetBeans.

Eval: Can't test described behavior now, lowering priority as it's edge case and
workaround exists. 

I can now reproduce this issue without VNC (though it is a bit hard). I believe
it is a race condition.

Here is what I do:

1) I use remote desktop to connect to a remote machine -- this probably isn't
strictly required but it slows things down enough to make it easier to reproduce.
2) Open up Netbeans 6.0 in one window and FireFox 2.0 in another.
3) Now... you'll have to use two keyboard shortcuts: ALT-TAB to switch between
windows and CTRL-V to paste.
4) Copy some text from FireFox, then *quickly* switch back to Netbeans and paste
it. Repeat this a second time and you will notice that the second time it'll
paste the text from the first time, then if you wait about a second and hit
CTRL-V a second time (without switching back to FireFox) it'll suddenly paste
the text from the second time around.

So to clarify: it looks like Netbeans clipboard buffer is being updated about
one second after switching focus to it. If the user hits CTRL-V quickly enough,
he will paste the outdated clipboard value. I suspect that if you fix this it'll
magically fix the VNC issue as well. In light of these new repro steps, please
consider increasing the priority of the issue back up.

I tried reproducing this issue without Remote Desktop but due to another
unrelated bug in Netbeans I am unable to do so. Basically if I hit alt-tab very
quickly to switch between Netbeans and FireFox then every second time the File
drop-down menu gets selected, such that when I get back into Netbeans and try
pasting it won't let me because the Editor no longer has focus. This behavior
does not occur for other (native) applications. I will file a separate bug
report for it now.

OK, raising prio back. Sidenote - I believe 91822 is in fact Swing bug, I
remember I reproduced it with SwingSet2 demo longer time ago.

*** Issue 92362 has been marked as a duplicate of this issue. ***

I'm getting this issue on my MacOSX as well. I notice mostly in this scenario.

1. open commit dialog
2. switch to firefox and copy the issue number in clipboard
3. switch back to IDE, paste in dialog.
--> often I get an older clipboard content, need to go back to firefox and copy
again.


no remote display in my setup.

I've been able to reproduce this locally as well. I tried copy/pasting from Visual Studio 2003 into Netbeans and the
clipboard still contained the old data. I hit ALT-TAB to switch to another application, then hit ALT-TAB a second time
then pasted using CTRL-V and this time the clipboard contents were correct.

dsimonek, is there some extra logging output we can enable to help you debug this on your end? I really would like to
see this bug fixed in NB 6.0!

I've just wanted to clarify one very important point: in my testcase I never COPY a second time. I do the following:

Copy from Visual Studio 2003
ALT-TAB to Netbeans
Paste (old data shows up)
ALT-TAB (goes back to VS2003)
ALT-TAB (goes back to Netbeans)
Paste (new data shows up)

The bug seems to be exclusively linked to application focus change. My guess is that Netbeans only retrieves the
clipboard contents when it gets some JFrame window event or something quirky like that.

Turn on logging with -J-Dorg.netbeans.core.NbClipboard.level=100

I don't think the logs I collected will provide you with enough information but I'll attach them anyway. I suggest you
add extra logging that actually mentions what text was copied into the clipboard.

My test-case consisted of the following steps:

1) Set focus to Firefox
2) Copy "material"
3) ALT-TAB to Netbeans
4) paste > "materials"
5) ALT-TAB to FireFox
6) Copy "drivers"
7) ALT-TAB to Netbeans
8) Paste > "materials"
9) Wait two seconds
10) Paste > "drivers"

   So it looks like the clipboard state is being changed asynchronously in between steps 8 and 10. That is, the Netbeans
does not guarantee that the clipboard state is up to date before allowing Netbeans to regain focus (as the user would
expect). The actual update occurs up to two seconds later.

Created attachment 47852 [details]
Log sniplet for the duration of the test-case

Created attachment 47853 [details]
full log for test-case (in case you want to check the broader context)

Passing to clipboard author Jarda, hope we have enough info now... 

I've added more logging for beta2, please generate the log again. Maybe with ...level=50

IDE:-------------------------------------------------
IDE: [7.9.07 14:18] Committing "NbClipboard.java" started
Checking in NbClipboard.java;
/shared/data/ccvs/repository/core/src/org/netbeans/core/NbClipboard.java,v  <--  NbClipboard.java
new revision: 1.33; previous revision: 1.32
done
IDE: [7.9.07 14:19] Committing "NbClipboard.java" finished

Is there a corresponding dev build I can try out seeing as beta2 is far off? Also I would appreciate you leaving this
issue open until I can confirm it has indeed gone away. It will make it easier for me to find in the future by clicking
on "My Bugs".

I'm attaching a new dump from dev build 200709090000.

1) Set focus to Firefox
2) Copy "condemn"
3) ALT-TAB to Netbeans
4) paste > "condemn"
5) ALT-TAB to FireFox
6) Copy "pessimistic"
7) ALT-TAB to Netbeans
8) Paste > "condemn"
9) Wait two seconds
10) Paste > "pessimistic"

Created attachment 48460 [details]
Log sniplet condemn/pessimistic testcase

As a potential workaround try:
-J-Dnetbeans.slow.system.clipboard.hack=false
or true...

Otherwise, as I understand, if you wait 2s, the clipboard updates itself and everything works fine. If so, then I 
guess this is p4. Annoying, but we have higher priority bugs.

FINE [org.netbeans.core.NbClipboard]: isDataFlavorSupported: 
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-openide-nodepaste;representationclass=org.openide.nodes.Node] 
result: false
FINE [org.netbeans.core.NbClipboard]: isDataFlavorSupported: 
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-openide-multinode;representationclass=org.openide.util.datatransfer.MultiTransferObject] 
result: false
FINE [org.netbeans.core.NbClipboard]: window activated scheduling update
FINE [org.netbeans.core.NbClipboard]: getContents by null
  2 = java.awt.datatransfer.DataFlavor[mimetype=text/html;representationclass=java.lang.String] contains: condemn 
FINE [org.netbeans.core.NbClipboard]: getContents by null
  2 = java.awt.datatransfer.DataFlavor[mimetype=text/html;representationclass=java.lang.String] contains: condemn 
FINE [org.netbeans.core.NbClipboard]: isDataFlavorSupported: 
java.awt.datatransfer.DataFlavor[mimetype=text/active_editor_flavor;representationclass=org.openide.text.ActiveEditorDrop] 
result: false
FINE [org.netbeans.core.NbClipboard]: Request for flavor: 
java.awt.datatransfer.DataFlavor[mimetype=text/plain;representationclass=java.io.Reader]
FINE [org.netbeans.core.NbClipboard]: Returning value: java.io.InputStreamReader@1ad7b78
FINE [org.netbeans.core.NbClipboard]: internal clipboard updated:
  2 = java.awt.datatransfer.DataFlavor[mimetype=text/html;representationclass=java.lang.String] contains: pessimistic 
FINE [org.netbeans.core.NbClipboard]: getContents by org.openide.explorer.ExplorerActionsImpl@1a49182
  2 = java.awt.datatransfer.DataFlavor[mimetype=text/html;representationclass=java.lang.String] contains: pessimistic 
FINE [org.netbeans.core.NbClipboard]: getContents by org.openide.explorer.ExplorerActionsImpl@1a49182
  2 = java.awt.datatransfer.DataFlavor[mimetype=text/html;representationclass=java.lang.String] contains: pessimistic 
FINE [org.netbeans.core.NbClipboard]: isDataFlavorSupported: 
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-openide-nodepaste;representationclass=org.openide.nodes.Node] 
result: false
FINE [org.netbeans.core.NbClipboard]: isDataFlavorSupported: 
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-openide-multinode;representationclass=org.openide.util.datatransfer.MultiTransferObject] 
result: false
FINE [org.netbeans.core.NbClipboard]: isDataFlavorSupported: 
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-openide-multinode;representationclass=org.openide.util.datatransfer.MultiTransferObject] 
result: false
FINE [org.netbeans.core.NbClipboard]: isDataFlavorSupported: 
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-file-list;representationclass=java.util.List] result: 
false
FINE [org.netbeans.core.NbClipboard]: isDataFlavorSupported: 
java.awt.datatransfer.DataFlavor[mimetype=text/uri-list;representationclass=java.lang.String] result: false
FINE [org.netbeans.core.NbClipboard]: isDataFlavorSupported: 
java.awt.datatransfer.DataFlavor[mimetype=application/x-java-openide-multinode;representationclass=org.openide.util.datatransfer.MultiTransferObject] 
result: false
FINE [org.netbeans.core.NbClipboard]: getContents by org.openide.explorer.ExplorerActionsImpl@208506
  2 = java.awt.datatransfer.DataFlavor[mimetype=text/html;representationclass=java.lang.String] contains: pessimistic 

I've added more logging, please simulate the previous test case once more. Thanks.


IDE: [10.9.07 13:37] Committing "NbClipboard.java" started
Checking in NbClipboard.java;
/shared/data/ccvs/repository/core/src/org/netbeans/core/NbClipboard.java,v  <--  NbClipboard.java
new revision: 1.34; previous revision: 1.33
done
IDE: [10.9.07 13:38] Committing "NbClipboard.java" finished

I strongly disagree that this is a P4.

From somebody not initiated into the workaround, cut & paste is just broken. The way I use cut & paste (and I suspect a
lot of users use it), is that when you need something, you go to another window, you copy it, you then go back into
NetBeans and paste it. I never spend more than two seconds after opening the NetBeans editor again before I paste it -
and it would always paste the WRONG contents.

It wasn't until somebody mentioned on one of the aliases that this was related to a delay I realized the "workaround" of
waiting two seconds. But even after knowing that, I still often get bit by this bug. 

I tend to agree with tor. This bug has been around for years and I consider it serious enough that it should be fixed as
soon as possible. I am doing my best to provide you with the logs you are asking for, hopefully this will encourage you
to fix it as soon as possible ;)

*** Issue 71786 has been marked as a duplicate of this issue. ***

I would appreciate it if other people also tried helping with the log generation. It is very time consuming and I've
been busy as of late. Will someone please step up to the plate? :)

I'd do it but this is marked as a P4. I don't want to waste my time if it isn't going to be fixed any time soon.

As a Mac user, I also don't agree this is a P4. It's really a P2.

Raising back to P2 and adding Tonda N to cc - Tondo what do you think?

Agreed that for users who don't know the mechanism and thus feel C&P is broken this is a P2.

Jardo, two suggestions from the top of my head:

1) Is there a possibility to speed up the clipboard update after NB gets focused? I guess this is not possible.

2) Could we change a Paste action handling, so that it waits for the NB clipboard update? This will make Paste action
responsiveness worse if triggered right after focus change, but it is better than the current state.

The issue is fixed on MacOSX (as can be verified by Miloš who helped me) and I have no problems to copy text between 
NetBeans and Internet Explorer on my Windows XP.

jtulach,

Are you saying you recently committed some code which fixes this problem? Which dev build will this fix show up in (I'd
like to verify it on my end)? Also, can you briefly explain what was changed or point me to the diff URL? Thanks :)

NbClipboard.java, revision 1.35
date: 2007/09/14 13:52:35;  author: jtulach;  state: Exp;  lines: +7 -2

I have reopened this issue because the diff indicates absolutely nothing was changed under Windows XP. Sorry jtulach but
this issue cannot possibly be fixed.

My gut feeling is that anebuzelsky is right, you should remove the clipboard caching taking place as discussed in the
comment "Therefore we cache the contents of system clipboard and use the cache when someone calls getContents()"

The comment goes on to state "It means if some other apps modify the contents of the system clipboard in the background
then the change won't be propagated to us immediately" which is exactly what we would like to be fixed here :)

We must reevaluate.

I did some further investigation and here is what I found.

- This hack was originally introduced in http://www.netbeans.org/issues/show_bug.cgi?id=38441
- Many of the issues this hack was supposed to have worked around has since been fixed in the JDK (especially for Unix)
- The one remaining issue is that if you disable the hack and navigate across nodes in the "Projects" tab then you will
see high CPU usage because every time you move to a new node Netbeans queries the contents of the clipboard. Simply add
"-J-Dnetbeans.slow.system.clipboard.hack=false" to your Netbeans command-line to see what I mean.
- It is my understanding that the only reason Netbeans queries the clipboard is in order to figure out whether the Paste
icon should be enabled or not. Now, ironically the editor always displays the Paste icon as disabled even if the
clipboard is empty. One wonders why the Projects tab couldn't do the same...? In fact this suggestion was brought up in
bug #38441 but no one seemed to have replied to it.
- Part of the problem with this issue is that it is very difficult to reproduce. As a result jtulach seems to be under
the impression it does not exist (see his most recent post) but it is impossible that the problem went away because
nothing of substance was actually changed in the clipboard code.

jtulach, I know that you are reluctant to deal with this issue because you are having a hard time reproducing it on your
machine but please understand that many of us here run into it on a regular basis and it is extremely frustrating. We
also know for a fact that this issue exists because the comment in NbClipboard.java mention it and it is a pretty
obvious race condition when you consider what the code is doing. So if we can all agree that this issue exists we can
discuss possible solutions. I have the following questions:

1) Does anyone know why Clipboard.getContents() is slow under Windows (or is this normal given the size of the contents
we are copying)?
2) Is there a way to find out if the clipboard is populated or the mime-type of the clipboard without retrieving the
entire contents?
3) Why can't we check the clipboard contents once, and cache those contents until the Netbeans window loses focus? That
is, how can external applications modify the clipboard while Netbeans has focus? If we cache this way we should be able
to update the clipboard synchronously when Netbeans regains focus without a serious performance hit.
4) Why is it okay for the editor to leave the Paste icon always enabled but it isn't okay for the Projects tab to do the
same? Isn't it preferable to display the wrong enable state than pasting the wrong clipboard contents?

I don't personally mind what priority you associate with this issue so long as we can set Target Milestone to something
reasonable, ideally 6.0. Please consider the fact that this issue has been around for 3-5 years now and I've put in a
lot of effort trying to help you track it down. I think you will find we are all more than willing to help you resolve
this issue if we are under the impression you are also committed to fixing it as well (see tor's comments for example).

The reason why this is not (in my opinion) P2 is that now the issue happens only on Windows and only using some 
strange config (search for "Netbeans open in a remote machine via VNC"). That means the # of affected people is too 
small to justify my time wasted on this.

If another independent reporter is able to reproduce the "old clipboard content" problem on Windows without VNC&co. 
I'd be happy to make it higher priority again.

So, first there are two users, Gili and Milos (not sure if Petr Jiricka was able to reproduce this too, that would be
3), having 2 or 3 reporters does not mean there are no more people impacted, for most issues you have one reporter.
Second, one is on XP and second on Mac. Third, no strange config is involved on Mac. Fourth, the first user is a long
time user and supporter of NetBeans (I know the user name from the time I worked on j2ee, there were many useful reports
from this user), are you telling this user that you do not care because it works for you? And finally, for fifth, I do
not think bug priority guidelines say anything about the number of effected users, it talks only about user impact.

Your wasted time has IMO nothing to do with a severity of an issue (we use "priority" but Bug Priority Guidelines
actually talk all about severity). How about other people's wasted time?

FYI - I haven't seen this problem on the Mac lately and it used to bite me ALL the time.

Tor, it could be because jtulach disabled the hack on MacOSX and it is my understanding that with the hack disabled the
problem goes away. The only reason the hack is still enabled on certain platforms (such as Windows) is that the native
clipboard access is said to be too slow.

jtulach, while it is true my original report talked about VNC you will note that on August 29th I posted a comment that
I able to reproduce this problem without it. Furthermore, thinking back, I've actually run across this bug for many
years now. Bugs were opened, closed as WORKSFORME and it went on this way until this latest bug report when we finally
narrowed down the problem to specific repro steps a code sniplet that is believed to be at fault. Again, I don't think
it is useful to argue semantics about what priority this bug should have but rather we should be focusing on what we can
do moving forward.

I've already offered a very simple fix: disable the hack on all platforms and leave the paste icon always enabled (i.e.
don't poll the clipboard so often). This fix should take you no longer than 30 minutes to implement and I believe it is
a relatively low negative impact (purely cosmetic). What do you think?

Re. Disabling on all platforms: That cannot be done. On UNIX OSes we are in risk of deadlock if one debugs an 
application that works with clipboard. Then any call to getContents waits for ever. Second problem is that the "30min 
fix" is inherently spread among many APIs (clipboard, nodes, actions) and as such its is more likely "30days fix".

I'll ask our QA to reproduce the problem on one of our machines tomorrow. If they succeed, I'll debug, test, fix it by 
6.0.

I can also confirm that everything now works fine for me on Mac. Still, if there is a problem on Windows, then this
issue is serious enough and should be a P2. And if the fix takes 30 days, then we'll need to waive this and fix for the
next release.

jtulach, I was under the impression the Unix problem is reduced by
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4818143

The evaluation seems to conflict a bit with the NbClipboard.java code because the evaluation says the timeout is not
configurable yet the code *is* setting some sort of timeout to one second. Any ideas?

As far as I know http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4818143 is integrated only in JDK6. We need a fix 
for JDK5 as well.

Fair enough. Is it possible for us to leave the cache enabled only Unix JDK5 for starters and move forward from there? I
was thinking of asking Sun to backport the fix to JDK5 but I am guessing this wouldn't help much because there are
already users without a fixed JDK, right?

From the QE point of view the P4 priority is accurate. It is not reproducible when doing copy paste between NetBeans and
native applications. The case with the VNC is the corner case and doesn't impact users with typical usage.

juhrik, this issue *is* reproducible when doing a copy/paste between Netbeans and native applications locally, without
using VNC. I'm sorry that I ever mentioned VNC in my original bug report because now everyone seems to be fixated on it :)

To recap: originally I could only reproduce the problem with VNC, but eventually I noticed that I could reproduce it
without it.

gtzabari, does it mean that you are able to provide 100% steps how to reproduce without VNC?
Thanks.

I posted reliable repro steps (without the use of VNC) on September 9th. The slower your machine, the more likely you
are to see this issue. Obviously you'll only see it 100% if you copy/paste faster than your particular machine can
handle, so if you happen to be testing with new hardware I wouldn't expect you to run into this very often. On my
particular machine I run into it 25% of the time.

The way I see it, you can reproduce problems with the hack on slower machines and there is no need for it on faster
machines (because Clipboard.getContents() runs without a noticeable impact) so either way I would say there is good
reason for us to update this code.

The same problem is reproducible 100% of the time with a utility that I use called ClipCache Plus
(http://www.xrayz.co.uk) that provides an enhancement over a standard clipboard.  Basically it keeps around recent clips
and allows you to select those and paste them into applications.  I have hotkeys defined which allow me to move up and
down the list of recent clips and then paste them in.

In all of my applications this works fine and in NB 5.x this worked fine, but in NB 6.0, this no longer works.  I've
corresponded with the author of this utility and he downloaded NB 6.0 last night to try to find the problem.  Here is
what he found:

   This is a bug in NetBeans I believe. When the
   NetBeans IDE is the active window it "locks" the clipboard, preventing
   CC (and anything else) from copying to the clipboard. That is why
   quickselect can't copy to the clipboard. Switching away from NetBeans
   removes the lock.

   To verify this, after using quickselect up/down (classic style) in
   NetBeans, do a Ctrl+V and old content is pasted, then switch away to
   the desktop (or any other window, thus breaking the "lock" that
   NetBeans has on the clipboard) and back to NetBeans IDE, you can now
   Ctrl+V to paste that clip.

Note that when this utility is used with hot keys, Netbeans never loses focus.  This must mean that this is running into
 tthe cached clipboard contents queried earlier.

It's funny that Netbeans is having such a problem with the clipboard but I use a few other Java based applications
(Squirrel SQL Client, Magic Draw UML, etc.) and none have the same clipboard problem.  Only Netbeans.  Also all work
mightly snappy with regards to the clipboard.

As I wrote above, I don't believe there is a need to maintain the clipboard hack for Windows at all if Netbeans simply
stops polling the clipboard so often. The hack causes much more harm than good in this case.

Under 6.7 and 6.7.1 it's still a problem. Copy from Firefox to NetBeans copies only any two times (or less) the old
clipboard content. Sometimes it works with waiting a few seconds on switching between the applications. From the user
side it's really a P2. 

Hi,
with 6.5.x I never had this problem. After the update to 6.7.1 it happens nearly very often when I copy something from
the firefox browser into netbeans.

WinXP, Netbeans 6.7.1, FF 3.5.2 

1. Mark text in browser
2. Ctrl + C
3. Ctrl + Tab to Netbeans
4. Ctrl + V => old content from the clipboard
5. e.g. Ctrl + Tab to Notepad++ 
6. Ctrl + V => new content from the clipboard
7. Ctrl + Tab to Netbeans
8. Ctrl + V => new content from the clipboard

I'm surprised that this problem is so old, because I never had problems with the version 6.5. This bug is very annoying
during the daily work!

Ciao,
Mike

I have the same issue since I am using Netbeans. I thought this was related to my VMware, because I am using NetBeans in
a virtual Linux (Kubuntu 8.0.4) on top of Windows XP. But reading this thread, I seems to be caused by Netbeans itself.

I did never notice the same problem in any other Application, neither under Linux, nor under Windows and also never when
using the clipboard to copy text from a host machine to a virtual machine.

I really wonder why this problem is not solved for such a long time.

The problem is not only related to Netbeans 6.7.1, I had it since 5.5 and with all updated until now.

Why is this bug not solved for such a long time? I guess it's because none of NB developers could reproduce this bug
reliably, making possible fix almost impossible. Also, it seems to be rather complicated if you look at the comments,
mostly from jtulach.

I don't know why this is assigned to window system (probably because of lack of "clipboard" category), passing to jtulach.

I summarized this issue nicely a few posts back. Please read my comment from "Oct 12 01:15:45 +0000 2007".

Im trying netbeans again, the 'no smarty' issue is still a huge one for me, but its coming in 6.9 and available with the development builds so im trying Netbeans again.

First thing i notice is that I am unable to copy anything from outside the editor to it or vise versa. eg from netbeans editor to firefox or firefox to netbeans.

The only exception is if i use the center mouse button to paste.

If i use ctrl+v then i get the last thing copied from the editor.  

steps;
1. highlight a line of code in the editor
2. click ctrl+c
3. open google.com with the cursor in press ctrl+v  (nothing, or the last thing copied OUTSIDE the editor will appear.)
4. click the middle mouse button and the line of code from the editor appears.

my setup.
2 kubuntu 64 bit 10.04 computers linked together with quicksynergy.
machine one:
* mouse and keyboard attached
machine two:
* running netbeans and firefox.

Netbeans is the only program that i have seen this functionality in.  Eclipse running in the same configuration has no issues with copy/paste which would seam to indicate that the JVM version is not the issue.

Love to get this sorted so i can try Netbeans again.  It has some really nice looking features, but copy/paste is a necessity.

I managed to get my issue with copy and paste sorted out thanks to this thread:
http://forums.java.net/jive/message.jspa?messageID=274214

In my case the issue was with synergy and kubuntu 10.04 64bit using synergy from the original source.

after following the thread and using the synergy plus 
http://code.google.com/p/synergy-plus/

same thing, just a forked version which worked. Instead of running synergy through quicksynergy i copied the old .synergy.conf from my ~/.quicksynergy/.synergy.conf to ~/

then in the terminal of the server

$ synergys

and on the client machine

$ synergyc -f 192.168.0.2

This is a known issue and is on the kubuntu wishlist for future versions at launchpad:
https://bugs.launchpad.net/ubuntu/+source/synergy/+bug/385529

hope this helps someone.

This problem is 100% reproducible with Advanced clipboard manager. http://acmgr.sourceforge.net 
its puts data on clipboard and simulates Ctrl+V. netbeans is only editor where this ends up pasting was copied before.

Guys,

This issue is 5 years old. It is 100% reproducible and the problem does *not* resolve itself if you wait 2 seconds. Netbeans keeps the wrong clipboard value indefinitely unless you task-switch away from Netbeans and back which is very annoying.

Very few bugs get under my skin the way that this bug does. Please fix it already!

There is absolutely no good reason for the clipboard hack to be enabled under Windows. Why not disable it by default?

For what its worth, PhpStorm has similar issues too.  Eclipse was fine.

From searching I think its related to an issue with using Java Swing for the UI layout.  (eclipse doesn't use swing and didn't have this issue.)

related stuff:
http://netbeans.org/bugzilla/show_bug.cgi?id=40785
https://bugs.launchpad.net/ubuntu/+source/synergy/+bug/207057
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4818143
http://youtrack.jetbrains.net/issue/WI-1458?projectKey=WI&query=jre

Its marked as "Wont fix" in PhpStorm.

A quick clarification:

- There was a Swing-specific problem under Unix that leads to a deadlock if one debugs an application that works with clipboard.
- Netbeans introduced a workaround henceforth known as "the hack".
- The underlying problem was fixed in JDK6: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4818143

Now, here's the thing:
- Windows never had a problem. There is absolutely no good reason to enable this hack under Windows.
- It looks like there is no good reason to keep the hack enabled even under Unix. Originally the Netbeans team refused to remove the hack because they had to support JDK5. Now that Netbeans required JDK6 it should be safe for them to remove the hack altogether.

Please:
1. Remove the hack from Windows immediately. No one has disputed the fact that it's doing more harm than good.
2. Verify whether the JDK6 fix works under Unix. If so, consider removing the hack altogether (from all platforms).

I await your response.

Bugg still present!!!
Windows Server 2008 R2

Please,  remove the hack from Windows immediately.
Att least when will it be fixed?

eskes,

As much as I appreciate your enthusiasm, please don't mess up the version/OS fields. Version indicates the earliest version the problem is present in (which is 6.0 or earlier). By changing OS to "other" it's less likely anyone will fix this issue because they won't know it's Windows-specific. Finally, "target milestone" is only supposed to be set by committers.

I agree with you there is absolutely no point to keeping the hack enabled in Windows. It causes bugs with absolutely no gain. Netbeans committers, please consider enabling this hack exclusively under Linux (which is the only operating-system that used to require it, I don't think it still does).

the hack is turned off by default in core-main 00cb5837679d

Thank you saubrecht.

Guys, please try the following test once the fix shows up in nightly builds:

1. Copy a large amount of data into the clipboard using some 3rd-party application.
2. According to source-code comments, Netbeans reads the clipboard contents quite often during general usage which may lead to slowdowns. Let's see if this is still the case.

Source: http://hg.netbeans.org/core-main/file/00cb5837679d/o.n.bootstrap/src/org/netbeans/NbClipboard.java#l130

Btw. The expected slowness is likely mitigated by fix for bug 192317 in 7.1 code base.

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/00cb5837679d
User: S. Aubrecht <saubrecht@netbeans.org>
Log: #88161 - turning 'slow clipboard' hack off by default

this fix is causing regression, see #202567

i've reverted the fix in core-main 2cb3e97aa3bb

until #202567 is fixed you can use command-line parameter -J-Dnetbeans.slow.system.clipboard.hack=false

Integrated into 'main-golden'
Changeset: http://hg.netbeans.org/main-golden/rev/2cb3e97aa3bb
User: S. Aubrecht <saubrecht@netbeans.org>
Log: backing out fix for #88161 because it's causing regression in #202567

FYI: Bug 202567 is fixed, yet there is some uncertainity about it expressed in bug 203826...

Please update target milestone since 7.1 has been released.

Keep getting this and I'm on 7.1. Never had this issue before. Closing and reopening netbeans resolves the issue but it's pretty annoying

Got this with 7.1.2, also closing IDE helped

*** Bug 213044 has been marked as a duplicate of this bug. ***

New NetBeans user here - finding same problem (Windows Svr2k8R2) when using NetBeans 7.1.2 on remote machine via MS remote desktop (term svr). Never seen anything like this with any other app before - Windows clipboard always been rock solid across remote desktop. Annoyingly disruptive to work flow and, in my view, enough on its own to deter further use of NetBeans. Not familiar with Java myself but puzzled to see some of the discussion re manipulation/performance of Windows clipboard. My own experience (C++) with it has always been without problem.

I just encountered this bug.

It seems to happen when the windows clipboard is empty. Once you put anything in your clipboard outside netbeans it then starts working again.

I'm on windows win7pro using nb 7.1.2, java 1.6.0_26-b03 64 bit in case that's needed.

hello

the same trouble on netbeans 6.x, 7.x even on 7.2 RC1 with  ClipMenu or any clipboard manager
on mac ;(

I have to switch to any other app to have a clipboard refresh 

does command + V could update the clipboard just before pate ?

"-J-Dnetbeans.slow.system.clipboard.hack=false" set in 

/Applications/NetBeans/NetBeans 7.2 RC1.app/Contents/Resources/NetBeans/etc/netbeans.conf

at line :
netbeans_default_options=

doesn’t work for me

I found this with 7.2 release. Combined with issue 188109 this renders NetBeans useless in some scenarios. I had to quickly create a NetBeans project and copy files from an Eclipse project. After 3 files copied, the clipboard inside NetBeans retained some old text string while I could copy files from Eclipse into windows explorer targets where I created the packages with NetBeans. NetBeans is good at refreshing the externally copied files and scanning, but the wole process was a nightmare because I could not paste the files into the Projects window.

So contrary to what was written before, this does not fix itself by using the clipboard in other applications.

Please do not modify "version". It is supposed to point to the first version this bug occurred in.

My observation in comment 80 was on WinXP, local C: drive, no VNC or anything like that. I have seen this on different computers before, each time in simple scenarios like this. Difficult to reproduce.

I created this account for the sole purpose of getting this bug promoted to P2 (P1 if i was in charge of it). I've suffered from this problem for one year and two months (the length of my employment at this company), and this bug is so annoying that if i wasn't required to use Netbeans i wouldn't use it at all. This bug makes me want to smash my computer into pieces.

At work, I am copy/pasting things into and out of netbeans about every 10 minutes in an 8 hour day. I check every few weeks, hoping there is a fix out, but nothing. I've finally read this whole thread, and to have a programmer consign his fellows to the literal hell caused by this bug is disturbing, especially after all the work gtzabari has done to identify the problem for you. This bug is so bad that i have to use a search program to find the file I want to copy from, open it in Notepad++, and copy from that.

The workarounds posted in this thread do NOT work.
Restarting Netbeans works maybe for one or two pastes and then it goes back to not working.

I cannot contribute log files because we deal with sensitive financial data :(


Windows 7 Professional 64-bit
4GB RAM
AMD Phenom II P840 Triple Core Processor 1.90 GHz
NOT using VPN, thing copied from and Netbeans copied to are both right here.

(In reply to comment #83)
> I created this account for the sole purpose of getting this bug promoted to P2
> (P1 if i was in charge of it). (...)

I too suggest P1. No editor is usable without proper clipboard functionality.

> (...)
> The workarounds posted in this thread do NOT work.
> Restarting Netbeans works maybe for one or two pastes and then it goes back to
> not working. (...)

One workaround that does work most of the time (atleast until the next hangup)
-when you see old clipboard data being pasted:
1. copy something else in NetBeans
2. paste it back to NetBeans (verify that this is not old data)
3. try again to copy from external resource.

NetBeans IDE 7.2 (Build 201207171143)
Windows 7 Enterprise 64-bit SP1
4GB RAM
Intel Core2 Duo T9400 (2x2.53GHz)
NOT using VPN

A bit of further information...
It isn't just a problem with the editor.  I just had the issue copy and pasting some setting to the Project Properties.

NB 7.1

Not using VPN.  Not using Remote Desktop.  Windows XP.

This workaround worked for me
>>1. copy something else in NetBeans
>>2. paste it back to NetBeans (verify that this is not old data)
>>3. try again to copy from external resource.

Has happened to me too with NB 7.2 on Windows 7 x64. JDK 1.6.0_32.
Very annoying.
Maybe have something to do when copy/past from/into the string "".
A java program was running in the background in the debug mode, however no brakepoints or etc.

And thanks for the work around! It works.

*** Bug 215804 has been marked as a duplicate of this bug. ***

One of the biggest reason why we need fast query to clipboard was explorer. Whenever people selected new node, we needed to update state of paste action. Slow clipboard access could kill the perception. However after my fix to bug 192317, updating of these actions should be performed in a background thread - e.g. it does not matter if we wait a bit or not.

I can simulate this "old clipboard data" problem with NetBeans running in maximized mode inside a VNC session. If I apply following patch, the problem disappears:

$ hg diff o.n.bootstrap/src/org/netbeans/NbClipboard.java 
diff -r a6a34b314d4b o.n.bootstrap/src/org/netbeans/NbClipboard.java
--- a/o.n.bootstrap/src/org/netbeans/NbClipboard.java   Mon Sep 03 09:51:52 2012 +0200
+++ b/o.n.bootstrap/src/org/netbeans/NbClipboard.java   Thu Sep 06 09:07:10 2012 +0200
@@ -218,18 +218,8 @@
                 // which immediatelly follow WINDOW_ACTIVATED event.
                 // This is workaround of JDK bug described in issue 41098.
                 long curr = System.currentTimeMillis();
-                if (lastWindowActivated != 0 && lastWindowActivated + 100 < curr) {
-                    lastWindowActivated = 0;
-                    
-                    syncTask.schedule(0);
-                    boolean finished = syncTask.waitFinished (100);
-                    log.log(Level.FINE, "after syncTask wait, finished {0}", finished); // NOI18N
-                } else {
-                    if (log.isLoggable(Level.FINE)) {
-                        log.fine("no wait, last: " + lastWindowActivated + " now: " + curr); // NOI18N
-                    }
-                }
-                
+                syncTask.schedule(0);
+                boolean finished = syncTask.waitFinished (100);
                 
                 prev = super.getContents (requestor);
             } else {

E.g. always try to sync the content of clipboard with its system state before getContents returns. Wait for 100ms for such operation to finish to avoid deadlocks with debuggees. 

In case there no objections I apply the patch and we'll see if it really helps in general (which I think it should).

Please verify ergonomics#21750762fe5c - if it seems to work we can consider backport to 7.2.

First, lets restate the JDK bug that started this all: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4818143

Everyone involved should please read the evaluation in full. We have two separate problems:

1. Apparently some native applications (e.g. emacs) freeze if you use them to copy a large amount of data into the clipboard and paste into a separate applications (even not Java). In other words, the "copier" does not respond within a reasonable amount of time. The evaluator seems to indicate this issue is specific to Linux but theoretically speaking perhaps the same thing could occur under other operating systems as well.

2. Copy data into the clipboard from a Java app, trigger a debugger breakpoint in that app, try to paste the clipboard. The "copier" will not respond because it is suspended.

Jaroslav,

1. The 100ms delay makes me nervous because it has the potential of introducing race-conditions into this bug. I'd rather use a much bigger timeout value to make it easier to reproduce if something goes wrong (say 3 seconds).

2. I'd like to propose an alternative which is harder to implement but more user-friendly. If a timeout occurs, pop up a dialog along the lines of: "Application <Copier> is not responding. Keep on waiting?" then provide two options:

a. Okay (wait some more)
b. Cancel (abort accessing the clipboard)

I would add one final piece of logic: remember the user's selection (if he chose to cancel) for 10 seconds at a time. Internally Netbeans could try accessing the clipboard 1000 times, but if the user recently chose "Cancel" we should automatically fail without waiting or asking again. Ten seconds later we should begin prompting him/her again.

What do you think?

Hello,

i have tried the daily build n° 201209070001 (there is a lot of trouble on it) but the copy/paste trouble is still there.

i have a precision on the V 7.2 :
i’m using ClipMenu on a mac and it store like 500 (or more) cp in the history 
when i do an alt+command+v that show the history menu and then a can chose any old item
when chosen it should paste right after to the app
in netbeans i have to a command+v to have the text pasted and that work !

but when i do a command+c inside netbeans and redo the last procedure it began to stop working
then i do a command+v the pasted text is the last on is copied form netbeans
if i witch to a « normal cocoa » application ;) and go back to netbeans and
do a command+v the pasted text is the one i have chosen in the history menu

i have no trouble on apache directory studio (i didn’t know if it’s a pure Java™ app)

The fix is not in daily build yet. Wait for notification in this bug.

Re. "nervous because of 100ms" - seems to work. Anyway just wait and do the paste again, I'd say.

(In reply to comment #92)
> Anyway just wait and do the paste again, I'd say.

That's the whole point of this bug report :) We don't think it's appropriate for Netbeans to paste the wrong contents, ever. Either fail a clipboard operation (and ideally tell us why), or succeed and paste the correct contents.

Integrated into 'main-golden', will be available in build *201209150001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)
Changeset: http://hg.netbeans.org/main-golden/rev/21750762fe5c
User: Jaroslav Tulach <jtulach@netbeans.org>
Log: #88161: Always refresh the content of system clipboard when getContents is being called. Wait only 100ms to avoid deadlocks.

*** Bug 218395 has been marked as a duplicate of this bug. ***

Copying content from Help|About does not work. This worked before.

Build 201209150001

Cannot cut and paste into dialogs such as file location into server properties.
Cut and paste in the IDE is more broken than before.

(In reply to comment #97)
> Build 201209150001
> 
> Cannot cut and paste into dialogs such as file location into server properties.
> Cut and paste in the IDE is more broken than before.

Possibly. This is an area which is better to stay untouched. Still, people want us to touch it in a hope to get better behavior.

Run with -J-Dorg.netbeans.NbClipboard.level=FINE and attach logs so we can analyze your behavior. Opening new bug (depending on this one) is preferred.

jedit 5.0pre1 on mac as the same trouble
so pure java app have a big trouble on reading the current clipboard buffer !

bunam,

That doesn't tell us much. For all we know, JEdit could be using a similar clipboard hack under the hood.

*** Bug 216398 has been marked as a duplicate of this bug. ***

This is so not fixed..
I code using netbeans 7.1.2, dbVisualizer and notepad++ mostly on windows7 64bit.
Netbeans lose the ability to copy paste from or to it, keeping the copy paste data it last copied from within itself.
This happens all the time to me. My resolution is restarting netbeans which is highly disruptive since we have multiple large projects that have to reload every time. Yesterday happened 5 times, today 2 times and its not even past 10 am.
Please address properly.
Fond regards.

Netbeans committers: why is this marked as FIXED if "bht" is not able to copy/paste in places he used to be able to? If there is a legitimate regression we should reopen this issue.

Swartblits, please do not modify the platform field. This problem affects all versions of Windows so the originally reported version is being used.

Swartblits, please note this issue is marked as fixed in 7.3 so you can't expect it to work in 7.1.2.

FYI, in NB 7.2.1, the Cut/Copy/Paste toolbar icons don't even enable/disable correctly. Use the mouse or keyboard to select files in Projects panel, and maybe 1 in 5 files will have the copy and/or paste button incorrectly disabled (this is random, and returning to the file will re-enable the buttons). Probably some race condition from Bug 202567 spawning threads.

I don't want to start a new bug.

I want to point out how stupid this whole thing is with enabling/disabling the cut/copy/paste buttons. JUST LEAVE THEM ENABLED (like they always are in the Edit menu), and stop fixing one bug after another with fixes that don't work. To think of all the user frustration and the dozens or hundreds of developer hours wasted on all this through the years... just so some buttons could be pointlessly disabled! BUTTONS WHICH NOBODY EVER USES AND WHICH DON'T SHOW UP IN THE TOOLBAR BY DEFAULT. Incredible.

This still happens on Netbeans 7.3.1 on java 7 jdk1.7.0_25.
At times netbeans refuse to accept text copied form an outside window e.g. notepad++.
When you paste it paste the last thing you copied in Netbeans itself.
Guys please at long last fix this...
The only way to make netbeans go back to normal is to restart the IDE which is very time consuming for large projects.

This bug is a bit too long. Please turn on logging with -J-Dorg.netbeans.NbClipboard.level=100 and create new one. The original report was fixed and if something broken remains, let's treat it as a new issue.

problems still occur on V8.0

Perfect, bunam: so read comment 107 and act according to it.

Filed bug #243774 related to this issue.

I hope not to be adding unrelated info to this issue, but I got here mainly from 

http://youtrack.jetbrains.com/issue/IDEA-114252, which is from PHPStorm issue tracker.

A similar issue is there, at least a conflict with clipmenu on osx, which might be related to this or now, what I found useful there is a very small and simple java app that seems to have the same bug, which I tried to solve but couldn't.

I cannot paste text in find dialog box so every time long and boring text i write manually i use netbeans 8.1 on mac so please fix

pinak1161,

Please open a separate bug report. We do not reopen issues once they are fixed, especially if the issue occurs in different release number.