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.
System clipboard seems to be always empty (or doesn't provide any DataFlavor) when we copy something in editor and try the following: DataFlavor[] flavors = Toolkit.getDefaultToolkit().getSystemClipboard(). getContents(null).getTransferDataFlavors(); System.out.println("LENGTH="+flavors.length); String text = Toolkit.getDefaultToolkit().getSystemClipboard(). getContents(null).getTransferData(DataFlavor.getTextPlainUnicodeFlavor()).toString(); System.out.println("TEXT="+text); LENGTH=0 and next line throws UnsupportedFlavorException. It causes that you cannot paste anything into an external application. It happens only on Linux, JDK1.4.2_08. Tested on build 200506061800. It is high priority because it breaks the commit validation suite. I will try to workaround problem until it is fixed.
Can you please evaluate this P2 issue? It's been a long time since it's been submitted. Thanks!
Will anybody care about this issue? I recall it is not P5 so that it is possible to leave it a few years and then close it. Or are you waiting for JDK 6.0 so that we will not use JDK 1.4.2_X for building IDE/running tests? This consistently causes commit validation to fail on my Linux machine. Thanks for attention. :)
This causes that the commit validation test suite fails on my system. Reproducible. Config: Linux - Fedora Core 1, Gnome, Sun J2SDK 1.4.2_08, NetBeans 4.2 development builds.
According to http://www.netbeans.org/community/guidelines/commit.html commit validation must succeed on developer's machine before commit. According to http://qa.netbeans.org/processes/bug_priority_guidelines.html if something blocks developer's progress it is P1.
Apologies. I've tested on my machine and it works fine. I'm wondering what could be the cause of this as the editor's part is fairly simple - the system selection is retrieved by component.getToolkit().getSystemSelection() and if it's non-null then clip.setContents(new java.awt.datatransfer.StringSelection(component.getSelectedText()), null); Romane, are you able to reproduce on your machine? If so, I'll make a debug build for you. Thanks.
I've also tried to check the regular clipboard operations Ctrl+C Ctrl+X and they work well too. In this case the JTextComponent.cut() (or copy()) should be called but I'll double-check again.
Instead of making a debug build, provide a source code patch. I always encounter the bug during commit validation test after the first build after source code update. I will apply the patch and put the obtained data here.
Commit validation goes ok on my RedHat Fedora 4. I suggest to ask for cooperation somebody from people on whose machines this bug occurs. Or provide the patch as Marian suggests.
The editor delegates to JTextComponent.cut() and JTC.copy(). The patch outputs to err whether action in BaseKit gets called and then whether the delegating to the mentioned actions occurs.
Created attachment 24021 [details] Patch that debugs cut and copy action execution
Thanks for the patch. The test failed, with the following output generated by the patched code: Copy action called target=org.openide.text.QuietEditorPane[,0,0,569x494,layout=javax.swing.plaf.basic.BasicTextUI$UpdateHandler,alignmentX=null,alignmentY=null,border=javax.swing.plaf.basic.BasicBorders$MarginBorder@fc1387,flags=296,maximumSize=,minimumSize=,preferredSize=,caretColor=java.awt.Color[r=0,g=0,b=0],disabledTextColor=javax.swing.plaf.ColorUIResource[r=153,g=153,b=153],editable=true,margin=java.awt.Insets[top=0,left=0,bottom=0,right=0],selectedTextColor=javax.swing.plaf.ColorUIResource[r=0,g=0,b=0],selectionColor=javax.swing.plaf.ColorUIResource[r=204,g=204,b=255],kit=org.netbeans.modules.editor.java.JavaKit@1fb0fc2,typeHandlers=] Delegating to target.copy()
This occurs to me as well
If any faces the problem again, please look at the messages.log file for message like "Cannot install our clipboard to swing components, TopSecurityManager is not the security manager". If it is always there, I guess we have the cause.
I have thought this was a known cause! I described it recently on NB-dev (see http://www.netbeans.org/servlets/ReadMsg?listName=nbdev&msgNo=31069). Yes, every time it failed and I looked at the console during startup, it contained this message. It failed at least 50 times and I looked at the console for the message at least 20 times.
I have this message "Cannot install our clipboard ..." in IDE log when editor test fails.
I see. First thing to do is to improve the log message.
Logging improved, but is going to be null anyway, imho. core/bootstrap/src/org/netbeans/TopSecurityManager.java,v <-- TopSecurityManager.java new revision: 1.19; previous revision: 1.18
After last change message is: Cannot install our clipboard to swing components, TopSecurityManager is not the security manager: org.netbeans.core.NbClipboard@16218f9
I've put there additional checks and logging. Either the makeSwingUseSpecialClipboard method will fail immediatelly and we will get stacktrace of who call it without setting up the our security manager. Or the manager is correct and we somehow do not get the necessary callback. Then you should see a list of stacktraces like the ones bellow. But the these are from successful run, when we get the callback we needed: [exec] java.lang.Exception: Perm: (java.awt.AWTPermission accessClipboard) [exec] at org.netbeans.TopSecurityManager.checkPermission(TopSecurityManager.java:303) [exec] at java.lang.SecurityManager.checkSystemClipboardAccess(SecurityManager.java:1368) [exec] at javax.swing.TransferHandler$TransferAction.canAccessSystemClipboard(TransferHandler.java:860) [exec] at javax.swing.TransferHandler$TransferAction.<init>(TransferHandler.java:802) [exec] at javax.swing.TransferHandler.<clinit>(TransferHandler.java:792) [exec] at org.netbeans.TopSecurityManager.makeSwingUseSpecialClipboard(TopSecurityManager.java:460) [exec] at org.netbeans.core.NonGui.run(NonGui.java:126) [exec] at org.netbeans.core.startup.Main.start(Main.java:387) [exec] at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:90) [exec] at java.lang.Thread.run(Thread.java:534) [exec] java.lang.Exception: Perm: (java.awt.AWTPermission accessClipboard) [exec] at org.netbeans.TopSecurityManager.checkPermission(TopSecurityManager.java:303) [exec] at java.lang.SecurityManager.checkSystemClipboardAccess(SecurityManager.java:1368) [exec] at javax.swing.TransferHandler$TransferAction.canAccessSystemClipboard(TransferHandler.java:860) [exec] at javax.swing.TransferHandler$TransferAction.<init>(TransferHandler.java:802) [exec] at javax.swing.TransferHandler.<clinit>(TransferHandler.java:793) [exec] at org.netbeans.TopSecurityManager.makeSwingUseSpecialClipboard(TopSecurityManager.java:460) [exec] at org.netbeans.core.NonGui.run(NonGui.java:126) [exec] at org.netbeans.core.startup.Main.start(Main.java:387) [exec] at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:90) [exec] at java.lang.Thread.run(Thread.java:534) [exec] java.lang.Exception: Perm: (java.awt.AWTPermission accessClipboard) [exec] at org.netbeans.TopSecurityManager.checkPermission(TopSecurityManager.java:303) [exec] at java.lang.SecurityManager.checkSystemClipboardAccess(SecurityManager.java:1368) [exec] at javax.swing.TransferHandler$TransferAction.canAccessSystemClipboard(TransferHandler.java:860) [exec] at javax.swing.TransferHandler$TransferAction.<init>(TransferHandler.java:802) [exec] at javax.swing.TransferHandler.<clinit>(TransferHandler.java:794) [exec] at org.netbeans.TopSecurityManager.makeSwingUseSpecialClipboard(TopSecurityManager.java:460) [exec] at org.netbeans.core.NonGui.run(NonGui.java:126) [exec] at org.netbeans.core.startup.Main.start(Main.java:387) [exec] at org.netbeans.core.startup.TopThreadGroup.run(TopThreadGroup.java:90) [exec] at java.lang.Thread.run(Thread.java:534)
At last we got some info with Jarda. Problem is caused by loading of window system during IDE starup. Loading of window system is performed in AWT thread at the same time as setting SecurityManager from main thread. Sometimes javax.swing.TransferHandler.canAccessSystemClipboard is set to false by winsys before NB SecurityManager is set. I attach call stack.
Created attachment 24259 [details] Call stack
cvs ci -m "#59701: If a code accessed clipboard in a period of time when one TopSecurityManager has been instantiated and makeSwingUseOurClipboard was called, then the clipboard support got disabled completely. Simulated and the simulated case fixed." /cvs/core/bootstrap/src/org/netbeans/TopSecurityManager.java,v <-- TopSecurityManager.java new revision: 1.22; previous revision: 1.21 done Checking in test/unit/src/org/netbeans/core/NbClipboardIsUsedByAlreadyInitializedComponentsTest.java; /cvs/core/test/unit/src/org/netbeans/core/NbClipboardIsUsedByAlreadyInitializedComponentsTest.java,v <-- NbClipboardIsUsedByAlreadyInitializedComponentsTest.java new revision: 1.2; previous revision: 1.1 done Checking in test/unit/src/org/netbeans/core/NbClipboardIsUsedBySwingComponentsTest.java; /cvs/core/test/unit/src/org/netbeans/core/NbClipboardIsUsedBySwingComponentsTest.java,v <-- NbClipboardIsUsedBySwingComponentsTest.java new revision: 1.5; previous revision: 1.4 done
Thanks to all who helped to fix this issue. I removed workaround from IDEValidation.java: /cvs/ide/test/qa-functional/src/validation/IDEValidation.java,v <-- IDEValidation.java new revision: 1.129; previous revision: 1.128