I am able to reproduce it only on Linux Fedora Core 2.

Discovered by NetCAT program participant - adding [40cat] prefix.

Doesn't seem to be specific for this dialog. I was able to reproduce
the same behaviour (on pfelenda's machine) also with the following
dialogs: New Watch, New Breakpoint and Edit URL.
They are created using DialogDisplayer => reassigning to openide
for evaluation.

please evaluate it yourself.  Until you have reasons to believe this
is a bug in openide, don't assign it to openide.  Core is not a
dumping ground.

Thank you

I saw the same problem also with other dialogs (e.g. the New File
wizard). In most cases, it was reproduced on a remotely connected
Linux desktop, but it was reproduced also on a local desktop.

The symptoms are exactly the same as the symptoms of JDK bug #5097241
- "None of the comps in FileDlg receive keyevents on Solaris9 (CDE)
with XToolkit" (see
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5097241).

Also the synopsis mentions only Solaris, the reporter states in the
bug's description, that "This is reproducible when logging into a
remote linux machine through ...".

Correction:
The third paragraph should start with "Although ...", not "Also ..."

The same problem has been reproduced also in the following dialogs:

   New File (wizard)
   New Breakpoint (debugger)
   Rename Package (refactoring)

As for the Rename Package dialog, it is special in that the dialog was
invoked by a mouse.

Reproduced with various dialogs on Linux with JDK 5.0. It may be a JDK
bug, but we need to do more investigation to be done on our side.

Re-assigning to core. Yarda, I know you've done some debugging on
this. Please add your comments here. Thanks.

Changing subcomponent.

Amusement story at the begining: I managed to simulate the problem under 
debugger, but it was imposible to debug, as when I switched to another instance of 
NetBeans and back the problem got fixed. That means, we have a workaround - if 
you get into this situation, just switch to another application and back and the 
dialog becomes "typable". 
 

I succeed with debugging then - I started another X server and run each  program 
in own display. The problem is caused by code that is desiigned to delay 
keystrokes until a component is focused probably to prevent keystrokes to be 
delivered to wrong window (as far as I know it is new to 1.5). Sometimes the code 
gets confused, probably by the dialog not receiving focus. 
 
I'll add two pictures showing that the array of typeAheadMarkers is not empty. 
Imho this is bug in JDK, I can fire one for them. But please, focus experts speak 
up if you think that this can be  something we are causing. 

Created attachment 18475 [details]
Taken after the dialog got the focus - this shows that the array of the typeAheadMarkers is not cleared even it should be

I assigned this bug to david to tell us more about the focus.
Personally I suggest to close it as wontfix and add one bug to jdk
team describing what happens. Plus maybe add this as release note, the
you may need to switch to anothe app and back to fix the problem.

More info for consideration:

The bug was reporduced by me on Fedora Core 2, WindowMaker standalone.
I use jdk 1.5 to run netbeans and encountered a really annoying bug
in jdk 1.5 that is about jdk 1.5 apps stealing focus.

Here is the reference. Maybe this is the bug that preventing NetBeans
to function correctly. I would be happy if it's the case, otherwise I'm
afraid that the bug filed against jdk will be fixed after 2 yaers or so.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=5094112

From focus point of view, I'd say Netbeans does nothing bad or
dangerous in focus area that may result in bug we're talking about. I
checked again and no extra focus calls when opening Dialogs AFAIK. I
also recommend to close as wontfix and file a bug against JDK team, I
think Yarda's investigation is deep enough.

Seems like problem in JDK.

jdk bug 6183877 does not seem to exist.
Are you sure it's a correct number?

The bug does exist. I've just checked it. I think it takes a couple
days to propagate it from the Sun internal bug tracking system to the
JDC Bug Parade. Please try again later.

I am able to reproduce similar (or the same not sure how to verify)
problem with focus: When I open Find dialog from Projects tab on some
package node it looks like focus is in Substring edit box but I cannot
paste or write any character to it. When I click to Regular Expression
edit box writtens/pasted chars appear here and then I can click and
write into Substring edit box. Also when I close Find dialog focus
does not return to Main window. It is annoying bug but simple
wrokaround exists as described. I just tested JDK 1.5.0_02-ea-b02 and
it does not happen. (It also does not happen in JDK 1.6.0 build 11.)

Yes I admit I do not have typical configuration: I have exported X Win
from my notebook with FC2 to desktop with RH 8 + Gnome. I run Gnome.

I am not able to reproduce it anymore even with JDK 1.5.0. Weird. So
my previous post is irrelevant.

*** Issue 52674 has been marked as a duplicate of this issue. ***

closing

*** Issue 65066 has been marked as a duplicate of this issue. ***

*** Issue 64922 has been marked as a duplicate of this issue. ***

*** Issue 67366 has been marked as a duplicate of this issue. ***

*** Issue 69179 has been marked as a duplicate of this issue. ***

Happens to me all the time, when opening cvs commit window as well as new 
watch dialog. 

Created attachment 27268 [details]
A bit of reflection to detect the typeahead starvation and flush content of the key buffer

#50423: Use -Dnetbeans.hack.50423=true to enable reflection based workaround 
for the type ahead problem 
 
new revision: 1.8; previous revision: 1.7 
done 
Checking in windows/src/org/netbeans/core/windows/services/NbPresenter.java; 
/cvs/core/windows/src/org/netbeans/core/windows/services/NbPresenter.java,v  
<--  NbPresenter.java 
new revision: 1.26; previous revision: 1.25 

The JDK issue has been already fixed for upcoming JDK 6.0, closing

*** Issue 71678 has been marked as a duplicate of this issue. ***