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.
Try following (seems to be always reproducible on Build 200303131400, W2000, 1.4.1_01): * create in a package new "Java Class" with abcd name * the file abcd should be opened in editor and cursor should be at the beginning of the file * press CTRL+F3 and type "abcd" then press Enter * first found occurance of abcd should be selected and a few other occurences should be highlighted * now delete "d" from the abcd and you will see that all other highlighted occurences of abcd were unhighlighted. That seems to be wrong. If you type "d" back, nothing has changed, but use arrow down and scroll down the text -> once you reach the line with "abcd" it will get highlighted again. Looks like regression, consider increasing to P2.
Increasing priority. This is pretty annoying and I found additional scenario which makes this even worse: * repeat all the steps in the previous testcase including the deletion of "d" character * now move the caret one line up and press F3. Not only the results are no highlighted, but the editor is not able to find them anymore - pressing F3 will give you red status bar with text "'abcd' not found" although there still is couple of "abcd" in the text (name of the class and name of the constructor), only the first one occurence was modified. Thanx for evaluating.
The issue is likely caused by integration of fix for http://www.netbeans.org/issues/show_bug.cgi?id=20552 I'm investigating it.
Although rolling back the modification described above helps to get rid of the issue, the real reason of the bug is migration of the BaseDocument to gap-based storage and bug in BaseDocument.find(). Some finders e.g. all string finders such as FinderFactory.StringFwdFinder need to go back several characters in certain situations. If they need to step back to the other side of the gap then the search will not succeed although it should. I have a fix for the issue but I'm still testing it by automated tests now.
I have fixed the issue in main trunk. Diff: http://www.netbeans.org/source/browse/editor/libsrc/org/netbeans/editor/BaseDocument.java.diff?r1=1.95&r2=1.96 Mato, can you please review the fix? Thanks. I think the issue is a serious regression because it makes the whole search functionality unreliable. Therefore I would like to ask QA to allow this issue to be fixed in release35.
The diff looks OK.
Verified in NB dev 200304100100. It could be fixed in release35.
Raising prio, should be fixed in release35.
approved for 3.5
Merged into release35: Checking in libsrc/org/netbeans/editor/BaseDocument.java; /cvs/editor/libsrc/org/netbeans/editor/BaseDocument.java,v <-- BaseDocument.java new revision: 1.92.2.1; previous revision: 1.92
Verified fix in release35 build 200304132350.