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.
Same as Sun Java Studio bug 5060373. Steps to reproduce: 1. Generate output in the output window 2. Select and copy some text from the output window 3. Paste the text in any other text-based application on your machine. One of two things will happen here: 1) The text will be the correct text (9/10 times), or 2) the text is the previously copied (stale) text. 4. In either case, go back to the IDE and paste into an editor window. The text will ALWAYS be the same as what was pasted into the other application. This suggests to me that perhaps there is a problem closing or committing the clipboard after making a copy, and perhaps pasting into the non-IDE app is forcing closed the clipboard when crossing application boundaries. Also note that in all cases, pasting text into the IDE from other applications always works as expected. I am looking into this in the Java Studio codeline. But it appears that the same problem exists in NB 3.6.
this is not limited to the output window but in fact the whole copy/paste mechanism. This is a fairly complex and ugly problem. See issue 41098 for detail. Be very careful if you want to backport the fix. I wouldn't recommend backporting, it's not P1 and the consequences can be very bad *** This issue has been marked as a duplicate of 41098 ***
For what it is worth, this issue seems to be slightly different from 41098. If you observe the description. Our scenario's problem occurs when we STAY within the IDE boundaries, not when we cross app boundaries as in 41098. In fact, crossing app boundaries is actually the workaround for this particular bug. I have done a local test where I backported the trunk verion of NBClipboard. The NBClipboard 1.20 compiles fine and appears to work fine. However, it also appears to have zero positive effect on the problem that I have described here. However, I will not deny that there might be some relationship between the phenomenon described in 41098 and the phenomenon described here. By setting breakpoint in NBClipboard.setContents I have observed that the NBClipboard.setContents is not being invoked at all when the CTRL-C is performed on the Output window. CTRL-C's performed on almost every other editable region of the IDE (java editor, property editors, node names, etc) all trigger a break in NBClipboard.setContents. However, a CTRL-C on the Output Compiler errors window does not trigger the same code path at all. I do know that with or without the NBClipboard patch, a user can workaround this bug by following these steps: 1. Make the copy in Studio's "Output-Compiler" window. 2. Give focus to any other app besides Studio - this is the workaround step. 3. Return focus to the Studio and make your paste. I will change status to reopened. If after considering this additional information, you still feel it is a duplicate, I trust your judgement.
I see the difference. This is likely bcs output window lost key binding. I remember a similar bug in the past which was supposedly fixed in trunk (4.0) frisino: you said it works in most cases, but there is 10% chance that it's broken? OS? JDK? Have you tried to reproduce it with 4.0 build? Tim, please investigate
i will try to clarify. I think the original steps to reproduce which i copied from studio bug report are misleading. Apologies. There was a larger discussion in studio bug report and i tried to take just the last part, but it is misleading. Forget that descriptions. Here is better one: Steps to reproduce. 1. open java file in java source editor window 2. add some garbage to source to intentionally fail compile 3. compile java file F9 - this generates output in Output-Compile window. 4. change focus to Output-Compile window. 5. Select some or all of the compile error text 6. Ctrl-C to copy the selected text 7. change focus back to java source editor window 8. Ctrl-V to paste The bug is that the copied text is not what will be pasted. Instead the paste will be whatever was in the copy buffer BEFORE these steps were transacted. That bug is probably 100% reproducible, at least it has been for me. Following those steps 100% reproducible in Studio and NB 3.6 Now, the next observation - to observe workaround Follow those same steps listed above to create the problem scenario. At any point following the step 6 Ctrl-C action in Output-Compiler window give focus to ANY OTHER application on your desktop. At this point you can paste into another app (notepad etc) and will see the proper paste (i.e the text previously copied from Output-Compiler) At this point you can also return focus to NB/Studio and paste into the Java source editor, and also see the proper paste. Obviously, shifting focus to the OTHER app corrected something in the copy buffer or clipboard. Does that make it clearer?
one more thing which may be a separate problem. In my latest steps to reproduce - at step 6. Ctrl-C to copy the selected text - I have observed on several occassions, just now in NB 3.6, for instance, that it took several attempts for the Ctrl-C to actually even take, meaning for several attempts the "system beep" fired indicating that the copy had not succeeded. I understand where that "beep" is coming from, but I must stress that it may be a separate issue altogether because the failed paste occurs independent of the failed copy issue. The failed copy is traceable to the following observation confirmed by breakpoint analysis. While debugging remotely, I was finding that the TopComponent handling the copy action was OFTEN not the TopComponent one would expect based on the current focus in the IDE. For instance, if I set focus on the Java editor, ran a compiile to generate some text in the output window. Then shifted focus to the output window TopComponent, and then did the CTRL-C, my breakpoint on the performKeyBinding would occur in the JavaEditor$JavaEditorComponent (unexpected) instead of the expected TC, OutputTabInner. Under those conditions the copy action itself would fail to take - taking the code path that resulted in the system "beep" . Like i said, this phenomenon occurs and is verifiable but i am not sure of its relation to the stale clipboard issue.
i have not observed the problem in NB 4.x and I would not expect to because it looks like it has an entirely different implementation of "output" package "output2" if i'm not mistaken.
I think I know what the problem is. And yes, it's related to the hackaround we made to avoid the system clipboard deadlock. Facts first: it happens only in the terminal emulator (term for short) and this lib is not used in 4.0 codeline which has the new output window impl, simpler and better. What happened here is: * we wrap the system clipboard into org.netbeans.core.NbClipboard * all NB code access clipboard via NbClipboard * we use lowlevel reflection to force Swing text package to use NbClipboard * NbClipboard does its trick to avoid the system clipboard hang problem. In particular it sync its data with system clipboard only when ones switch from/to the IDE window And now the problem * we forgot about the terminal emulator which still accesses the system clipboard directly
Problem of terminal emulator which is not maintained now. NB 4.0 uses new impl of output window. Trung what to do with this P2?
*** This issue has been marked as a duplicate of 41306 ***
closed
moving terminal emulator issues to terminalemulator component. To see the correct version and target milestone of this issue look at Issue Activity table.