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.

Bug 117173 - Search-on-type loses first character
Summary: Search-on-type loses first character
Alias: None
Product: platform
Classification: Unclassified
Component: Explorer (show other bugs)
Version: 6.x
Hardware: PC All
: P4 blocker (vote)
Assignee: Petr Nejedly
Depends on:
Reported: 2007-09-30 18:51 UTC by kirillkh
Modified: 2008-12-22 11:32 UTC (History)
0 users

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description kirillkh 2007-09-30 18:51:07 UTC
1. switch to the Files view
2. start typing name of a file or folder
=> if you type fast enough, it will frequently lose the first character you type, so instead of "runnable" the Quick
Search bar will display "unnable". It won't position the cursor on the right file, when this happens.

This is an old issue, I'm pretty sure I saw it in 5.5 and probably 5.0, too.
Comment 1 Petr Nejedly 2007-10-11 11:37:21 UTC
Works for me and very reliably.
I tried switching using both mouse and Ctrl-2 shortcut.
I tried both sliding and docked explorers.
I tried it even on cold IDE, but it never missed a single letter.

Comment 2 kirillkh 2007-10-11 12:14:27 UTC
Did you try it on a slower machine with a large project open? I use Dell D505 laptop.
Comment 3 kirillkh 2007-10-11 12:17:08 UTC
Actually, the way I reproduce it is quickly typing two characters one after another. If I only type a single character,
it will always be displayed.
Comment 4 kirillkh 2007-10-11 12:21:23 UTC
BTW, why does "WORKSFORME" qualify as a resolution? It still doesn't work for me!
Comment 5 Petr Nejedly 2007-10-11 12:59:58 UTC
Worksforme is used to closing unreproducible issues.
After trying really hard, I managed to reproduce the problem (like in one of 50 cases and only when typing more letters
quickly at once), so reopening.
Comment 6 Petr Nejedly 2007-10-11 13:14:28 UTC
It seems that the problem was caused by a fix for issue 28501.
The first character is consumed by the tree component, it then prepares the search field, sets the text according to the
character and moves the focus to the search field. Subsequent key events should append the text to the search field.

But if the second key event come quickly enough, it still gets processed by the tree, replacing the first character.
This shouldn't happen in (otherwise synchronous) swing, as the next event can't come before previous is fully handled.
But the fix for #28501 delayed the focus transfer by redispatching it, so eny event queued in between (like the quick
additional keypress) gets handled in the old focus context.

As the fix for 28501 is no longer needed (JDK1.3 not supported anymore), this should be simple to fix.
Comment 7 Petr Nejedly 2007-10-11 13:23:04 UTC
Comment 8 kirillkh 2007-10-11 17:34:37 UTC
Excellent, thanks!