This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
NB200403161736, JDK1.4.2_03. Steps to reproduce: 1. Start the IDE with a clean userdir. 2. Open a source file (for example a Java source). 3. Select a line in the editor and copy it (Ctrl-C). 4. Paste it into the editor. 5. Select a piece of text in an external program (mozilla in my case). 6. Copy it (Ctrl-C in my case). 7. Try to paste it into the NB editor (Ctrl-Ins). 8. The text copied in step 3 is pasted instead of text copied in step 6. I was able to reproduce the problem also in the properties table (opened for a properties file), so I am sure whether this is problem in editor or somewhere else. Workaround: before step 7, paste the text from the clipboard into some dialog (for example Rename dialog for some file).
I am sorry but it works for me , the same steps as you mentioned only one change : 7. Try to paste it into the NB editor (Ctrl+V)
I have found why it does not work: There are two clipboards when using NB: internal NB clipboard and the system clipboard. These are synchronised at WINDOW_ACTIVATED event. This event is not fired on my system after workspace switch. I have one application per workspace and only switch workspaces if I want to work with another application. In this case, if I work with NB then change to the mozilla and then back to NB, no WINDOW_ACTIVATED event is fired and therefore the clipboards are not synchronised. Workaround is "-J-Dnetbeans.slow.system.clipboard.hack=false" I have Slackware Linux 9.0, KDE3.1.0, QT3.1.2.
verified
*** Issue 43153 has been marked as a duplicate of this issue. ***
Could somebody fix this? Is pretty annoying.
Hi David, I would like to ask you whether you can describe your environment, in particular: 1. Your OS. 2. Exact JDK version that you are using. Thanks.
WinXP, j2sdk1.4.2_04, 100% reproducible.
Ping
> Could somebody fix this? Is pretty annoying. Hardly. Direct usage of system clipboard was removed because of some P1s it caused. IIRC Yarda have implemented the clipboard hack, let him decide.
I've implemented just the part that convinces all swing components to use the internal system clipboard. The trick with window activated is provided by Trung. Adding him to CC.
I can fix anything, but having expert's insight is necessary. So Trung, please give us directions of what should be done, as you spend quite a few afternoons fixing this area.
*** Issue 44860 has been marked as a duplicate of this issue. ***
we can't do anything for Lahoda. If we don't see window_activated we can't do anything. But the David Konecny's case is different. On Windows it should work
this is so because we synch the system clipboard and the internal clipboard in a thread initiated after we get window_activated event. If the user press Ctrl+V before this thread runs the IDE pastes the old, not synch'ed yet clipboard. Unfortunately this is the only way how to fix issue 38441 and issue 40693. Both are very serious problem. The latter is even a P1 deadlock
And what about system selection in linux?? See issue 30513. Why doesn't work it now? It's very usable feature which shouldn't be removed.
sadly, it's not possible to fix without risking deadlock
great, we are back in 3.5
*** Issue 47023 has been marked as a duplicate of this issue. ***
Ok, so let's state the following: - This is still an open bug, at least under Windows (and from the comments I read above, Linux as well) - The underlying problem is a JDK bug which Netbeans attempts to work around. So now for some suggestions: - Why can't we synchronize the clipboards on other events than WINDOW_ACTIVATED? - Could someone actually explain in detail why the deadlock occurs? The JDK BugParade issue does not explain what is actually going on except that Emacs and other programs might be "pasting wrong". What the heck does that actually mean? Either way.... this issue should remain open until a solution is found. Right now the problem is *very* noticable when pasting from any native application into the Netbeans editor under Windows. It always fails.
see the other issues I mentioned which explain why this hack is necessary to fix the deadlock. The JDK engineers have confirmed that this is a problem on their side and plan to fix it. We don't plan to anything further on our side, thus the resolution is WONTFIX. If anyone has a better ideas what to do this problem, then by all means, reopen this issue. Otherwise nothing is likely to happen. Believe me we are fully aware of the problem and spent great deal of time on this and this the best we can do.
Trung wrote: "we synch the system clipboard and the internal clipboard in a thread initiated after we get window_activated event. If the user press Ctrl+V before this thread runs the IDE pastes the old, not synch'ed yet clipboard." - I see. So I tried it and waited some time before pasting to give the thread chance to finish. Did not help. "If we don't see window_activated we can't do anything. But the David Konecny's case is different. On Windows it should work" - so it seems to me that either on Windows you do not receive WINDOW_ACTIVATED or there is a bug. The workaround I found is: 1. switch to NB (paste does not work now) 2. switch to some other app 3. switch to NB (paste works OK)
which JDK are you using?
1.4.2_04 on WinXP.
I looked at this once again and cause is really in dependency on WINDOW_ACTIVATED event which is not delivered correctly. I patched NbClipboard.eventDispatched() method to dump events it receives and depending on how and especially how fast you press Alt-TAB (and I can press it pretty fast) I can observe following behaviour: when you are in NB and press Alt-TAB to switch to different application I can see that WINDOW_LOST_FOCUS and WINDOW_DEACTIVATED are received what is OK, but sometimes (and this is the bug) these two events are immediatelly followed by WINDOW_ACTIVATED and WINDOW_GAINED_FOCUS. The result is that Main Window thinks it has the focus (often the blinking caret is visible in editor) and if you copy some text in external app and switch back to NB no WINDOW_ACTIVATED event is received and therefore clipboard is not refreshed. I can reproduce it on both JDK 1.4.2_04 and 1.5.0b63. On 1.5.0 it happens more rarely. Reproducibility depends on speed of your fingers.
Created attachment 18051 [details] Possible fix - after focus gained, do full check when one calls getContents
Created attachment 18054 [details] just idea how to detect JDK bug
Yarda, your patch did not help. It just posponed task a bit. I attached what I had in my mind how to detect the JDK bug. I tested it and it works reliably. But I do not understand much clipboard code so I'm not sure how to use it. My idea was that if jdkBug variable is set to true the OS clipboard has to be re-checked next time somebody ask for clipboard content. Yes, it can result in problem which we are solving by the asynch task.
Created attachment 18058 [details] Strange my previous patch did not work. I've enhanced logging and wrote a test, David can you please run it and show me the log?
Created attachment 18076 [details] another patch
Did pair programming with Yarda, we merged patches and tuned it up. Looks we have workaround.
Yarda, my patch contains only NbClipboard.
Checking in src/org/netbeans/core/NbClipboard.java; /cvs/core/src/org/netbeans/core/NbClipboard.java,v <-- NbClipboard.java new revision: 1.20; previous revision: 1.19 done Processing log script arguments... More commits to come... Checking in test/unit/src/org/netbeans/core/NbClipboardNativeTest.java; /cvs/core/test/unit/src/org/netbeans/core/NbClipboardNativeTest.java,v <-- NbClipboardNativeTest.java new revision: 1.5; previous revision: 1.4 done Processing log script arguments... Mailing the commit message to cvs@core.netbeans.org (from jtulach@netbeans.org) ~/work/core$ cvs ci -m "#41098: Workarounding the JDK bug by detecting the wrong delivery of WINDOW_ACTIVATED and in such case doing fast (at most 100ms) system clipboard check for updated content. This part is mine, the JDK bug detection is provided by dkonecny@netbeans.org"
*** Issue 50249 has been marked as a duplicate of this issue. ***
Sad but this is still not fixed completely. I downloaded daily 20041012 or 13 and while it does not happen as often as it used to be, it still happened three times in a one hour session. Please take another look at this...
Logs, logs, logs. Fuerte, how do you think I am going to fix it, if you do not provide any info about what you are doing? Please run with logging enabled (-J-Dorg.netbeans.core.NbClipboard=-1) and attach the part of log that records what happened during the broken situation.
What if you try to fix it by logic: 1) It always works in the first time 2) It does not always work the next times So you must do something different... why not fix it by doing the same thing that you do in the first time?
Created attachment 18337 [details] Log file for failed clipboard paste
This one was hard to reproduce quickly. Finally I added a background process, burnp6.exe, running at lower priority, so that NB was still responsive. Then I switched to Notepad with Alt+Tab, copied "one", Alt+Tab back to NB, pasted "one", Alt+Tab to Notepad, copied "two", Alt+Tab back to NB, pasted "one" again. When I didn't have a background process running all the time, then it happened a lot more rarely. The OS is Windows XP, not linux.
Given the complexity of steps that are needed to reproduce the issue, I think we can adjust its priority.
Perhaps timeout it too low.
It was difficult to reproduce it quickly, that's why another process in the background was needed. At work I had Boinc running and it happened quite frequently. So basically external clipboard works now 100% if you don't have any other processes running on your machine... :-)
Still when I had the background process running, the first time paste worked fine. So what do you do differently the next time? When the background process was running, it still always worked the first time and always failed every other time (I think).
I think that I can hardly contribute to fixing an issue that works most of the time, and can be reproduced only on platform that I do not have.
Probably depends on #70741
"Why cannot we listen on other event than WINDOW_ACTIVATED" - issue 70741 will make the system listen on other event. *** This issue has been marked as a duplicate of 70741 ***
This issue had *1 votes* before move to platform component