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.
Problem is seen under automated tests, but likely can be seen during normal use of the IDE when a system is heavily loaded. Test system is Sierra FCS (EE), JDK 1.4, a somewhat slow single CPU NT box. Steps to reproduce: Create about 20 empty directories. In one directory create about 20 java source files each about 2K bytes in size. Repeatedly perform the following steps quickly (ideally in an automated test case). Select all 20 java source files created above. Context menu "copy". For one of the empty folders, context menu "paste". Perform these steps repeatedly as quicly as possible without waiting for the previous paste operations to complete. At some random point during pasting into empty folders a "bad" paste operation will occur. What gets pasted is the folder into itself. The theory I have for this behavior is that the copy operation returns control to the swing event handling thread before noting what is selected. When the IDE is bogged down with other paste operations, the selection will be changed by the new paste operation before it's copy thread receives control again. When the copy thread receives control it sees the new selection rather than what was selected when the copy menu item was chosen. This creates problems for some automated tests but probably will rarely be seen by users. For this reason I am suggesting P4.
reassigne to Jirka R. for investigation.
Maybe problem in node's copy/paste actions, reassign to openide/nodes.
Finishing the move to openide/nodes, as Jirka suggested.
Raising to P2 as part of effort to improve product testability. Adding T9Y keyword
Hmm, I see that this is a priority bugs for the test and low priority for usres. However I tried to reproduce it manually and I did not suceed. Could you please point me to the failing test or write a sample test case. Thanks.
Taking over the node bugs from phrebejk.
Doesn't influence user. Too little time in 3.6 frame.
The 3.6 changes all actions including Copy to run in AWT thread. That is why the copy action is now blocking and returns the control after the whole copy is finished. See http://www.netbeans.org/download/dev/javadoc/OpenAPIs/org/openide/doc-files/upgrade.html#3.6-actions-event-thread That is why the necessary conditions for this bug (e.g. do something "quickly") cannot be satisfied which leads me to a belief that this issue is not valid any more.
verified