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.
[200407131800] Test Case: testClipboard Test Suite: org.netbeans.core. NbClipboardNativeTest Module Name: core junit.framework.AssertionFailedError: correct string in clipboard expected:<17> but was:< * Created on July 13, 2004, 2:21 PM > at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.failNotEquals(Assert.java:282) at junit.framework.Assert.assertEquals(Assert.java:64) at org.netbeans.core.NbClipboardNativeTest.testClipboard(NbClipboardNativeTest.java:86) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
Created attachment 16235 [details] exception stacktrace
Not my code.
One line from cvs annotate: 1.1 (jglick 11-Feb-03): assertEquals("correct string in clipboard", "17", t.getTransferData(DataFlavor.stringFlavor)); Thus reassigning to jglick. Anyway I think that the test is interfering with some external changes. Maybe more tests or applications were running at the same time? If that was exceptional failure, I would just close it. Otherwise I woul think about running the test more times with same delay hoping that it will work at least once...
Hmm, I really don't know anything about NbClipboard any more and I have not been working on the code at all (Yarda and Trung are the only ones to work on it recently). Certainly don't remember what I might have put in the unit test a year and a half ago. Petr, any idea how long this has been failing? and on which platforms?
The test fails on windows and solaris. There is other solved issue #39373 for this test. It seems that the issue was not probably correctly fixed. See to the attachment where is report of runned test from 2004-07-04 00:56:35.812. This issue was reported for test report from 2004-07-14 07:12:58.0. There was some problems with ifrstructure for running unit test. I am not sure when was first failure of this test.
Created attachment 16318 [details] exception stacktrace from 2004-07-04
Unless someone knowledgeable about clipboard handling offers to work on this, this will not be touched anytime soon; I have no plans to work on it. No idea if the failure corresponds to any loss of user functionality. Will remove this test from the stable config in the meantime.
agree w/ Jesse, downgrade to P4
Caused by doing NbClipboard.setContent in async thread. As a result your might invoke Ctrl+C immediatelly followed by Ctrl+V and still get the previous content.
cvs -q ci -m "#46116: We have to waitFinished before doing getContent" ? X.diff Checking in src/org/netbeans/core/NbClipboard.java; /cvs/core/src/org/netbeans/core/NbClipboard.java,v <-- NbClipboard.java new revision: 1.18;
haven't look at the diff. but if the IDE is already in a near deadlock situation (the owner of the system clipboard is suspended), pressing Ctrl+V will cause deadlock? In other words do we timeout in waitFinished()?
the tests passed