Hmmm... It also happends when there are more than 1 class left, problem finding a pattern.....

Are there any exceptions in idea.log?

Nope, nothing in the log file... But I can provoke it, just once, by clicking the Project pane so it has focus and then pressing Ctrl-N..

Well, I have now done two things... Upgraded to build 98.311 and switched from JDK 32 bits to JDK 64 bits and I haven't yet bumped into this problem... Not sure if there is something you have done in the latest build or running 64 bits but I guess somehting has been done in the latest build....

Hmmmm... And now it happend again.... And still no log...

Still the same in 98.382... Please find a fix for this, this is really annoying....
BTW, I am using Linux if this might be OS specific...

Think I've had a breakthrough... :)
I always enable "Focus follow mouse" and it seems that this is the problem... If I enable "Click to focus", I don't get this error anymore, it seems... So I guess the reason it sometimes works ok, is that the mouse is positioned in the right place for it to work...
But this is new, never had such a problem with earlier versions of IDEA... And I don't want to enable "Click to focus" on my system to be able to use IDEA....

Can you please fix this.... Using IDEA 10 is not really "Development with pleasure" anymore, this bug is really annoying!

Try running Linux and XFCE and enable Focus follows mouse, and you will see how annoying this is!!

See you have marked it as duplicate and I see there that it proposed a solution changing a setting... While that works (as in not closing the dialog), it is not really a solution... .What I don't understand is why this doesn't work anymore... Never had this problem with IDEA 9 and earlier, what have you changed?? And can you change back?

We have made many changes to popup implementation, mostly having to do with lightweight versus heavyweight popups. No, we cannot change it back.

Hmmm... Don't you change to improve things and not to go backwards?

Yes, we generally do. But if a change brings many improvements and one regression, it's still better to keep the change and not to roll it back.

Yes, but my problem is I don't see any improvements; I only keep getting this really annoying dialog close thing which keeps me from developing with pleasure..
But I see that I only have to learn to live with it...

Unfortunately the provided fix (Deactivate setting: "Hide navigation popup on focus lost") doesn't really improve the behaviour.
Tested with EAP build 111.255 using Windows 7 and XMouse.
The navigation popup (Ctrl-N) doesn't hide any more but the cursor still disappears from ctrl-n text field and moves to underlying editor.
Reproduction:
1) Ctrl-N

• > Mouse cursor is NOT within the bounds of the input text field

2) type characters ("ABC")

• > the class list appears
  
• > mouse cursor is now within the bounds of the opened class list

3) type next character "D" (ABCD) which reduces the class list

• > mouse cursor is NOT within the bounds of the reduced class list
  
• > Cursor moves to underlying editor (in constrat to the behaviour before the navigation popup keeps visible, but any typed character appears in editor instead of navigation input field)

:((((((

I'm afraid I have no idea how to improve this behavior, other than leaving empty space within the popup when the number of elements to display is reduced.

i would be happy with this solution
probably you can make this empty space transparent or fill it with some useful info, but just leaving a blank area is also fine

Is there not an API for the text field component to request focus after resizing the popup?

There is, but it won't solve the problem. The focus will escape again after you move the mouse.

Well, I think that might be a viable solution... At least I never touch the mouse when using this feature...

Neither do I - we are talking about a key-shortcut feature ...

+1 to neither do I.
Also in my experience (running metacity on Linux) focus does not change when moving the mouse within a window, only when mouse movement crosses window boundaries. However I don't know how this is affected if you're using lightweight GUI components and managing them yourself rather than system-provided components.

agreed
the only case when i use mouse together with this popup is to select several items from list (would be nice to have a way to do it with keyboard only, for sure)

I rarely use the mouse, but sometimes do, but regardless of that, I hardly think a 'non-mouse' solution is acceptable...

Mark, perhaps you misunderstood
nobody is suggesting that you would not be able to use mouse for this popup
ideally, every feature should be accessible by using only mouse or only keyboard, none should require both at the same time

currently this feature requires me to use both mouse and keyboard which is annoying and disrupting

one more workaround i can imagine - automatically put mouse cursor over popup textfield when it is invoked, looks like it should be really easy to implement

Please try 11.0.2 final and make sure you uncheck Settings | Appearance | Close navigation popups on focus loss

That's better... Looks a bit weird but way better than the annoying loss of focus.... :)

as i said, the focus is still lost if the popup list changes its width
http://www.screenr.com/JFws

I don't think I misunderstood did I? I consider it broken if you can narrow with the keyboard and then can't select with the mouse. I do that quite commonly, though not always, it just depends on how the list changes. Snapping the mouse into the dialog might be workable, though this whole thing smells a bit off - just adopt a well-proven dialog behaviour and implement it. Please don't leave it half broken after all of this pain.

Mark,
Please try 11.0.2 final. Mouse selection should work just as well as it did before.

I'm not sure what you mean by "well-proven dialog behavior" in this case.

still broken with 11.0.2 (111.277)
:(( This is really annoying.

Repro (same as with EAP build 111.255 -> see my post above):
The navigation popup (Ctrl-N) doesn't hide any more but the cursor still disappears from ctrl-n text field and moves to underlying editor.
Reproduction:
1) Ctrl-N
* > Mouse cursor is NOT within the bounds of the input text field

2) type characters ("ABC")
* > the class list appears
* > mouse cursor is now within the bounds of the opened class list

3) type next character "D" (ABCD) which reduces the class list
* > mouse cursor is NOT within the bounds of the reduced class list
* > Cursor moves to underlying editor (in constrat to the behaviour before the navigation popup keeps visible, but any typed character appears in underlying editor instead of navigation input field)

Sebastian,
Did you turn off the "Close navigation popups on focus loss" option in Settings | General?

Dimitry,
of course I did. Otherwise the navigation popup would disappear/hide in step 3)

Tx Dmitry, trying it tonight. Good news is it indexed nice and fast - 3 minutes vs 5-10 normally (huge project).
I am seeing a lot of this though (off topic, sorry)...

Error while indexing /usr/lib/python2.5/pstats.py
To reindex this file IDEA has to be restarted

Ok, what am I doing wrong? I have Version 11.0.2 IU-111.277, but I don't see "Close navigation popups on focus loss" option in Settings | General.
I see 3 startup/shutdown options and 4 synchronization options.

Mark, the option is under Settings | Appearance, just above the Look and Feel combo.

OK, tx, got it now. I'll check it out over NX tonight. At work it seems ok with the option changed, but it's completely unusable with the default setting - the dialog won't even stay up for more than a millisecond - honestly guys that's crazy, the damn thing should just work. Ubuntu 10, focus follows mouse. Also, I see the popup window has a title bar (I don't see that in IJ9), which tells me straight away it's not a normal dialog box and you are fighting the window manager, so I doubt good things will come of this... We'll see.

Ok, I tried it over NX. Unusable. It started off ok, but at one point I clicked in an edit form and unlike my above report, where nothing happened (specifically, it did not dismiss the dialog as expected), here, the drop down file list part vanished, leaving me with a title bar and the file name box. All I could do at this point was close it with the close button, and it did close, but after this I could not relaunch the popup at all, so it was completely unusable at this point. Do you guys test this thing at all? Really? It's just a dialog box, why is it still broken after two major releases and countless bug reports/feedback? Looks like I'll be sticking with IJ9 for a while longer.

I am pleased to report though, that scrolling and general redrawing behavior over NX seems to have greatly improved, it used to be deplorable over NX, crazy slow and jerky scrolling and redrawing if you say resized the left column. But now it is a lot better, I wouldn't call it great, but it is usable. I'm pleased with that, though it should really be better.

Indexing also seems MUCH faster, like 2-3 times faster, but I'm suspicious it's not indexing as much as it used to, because now I find that JavaScript completion is extremely slow, like 30 seconds just to launch the selection popup. This is when you type foo. and it tries to complete the properties of foo. I didn't a/b that with IJ/9 though, I'll do that tomorrow, but it certainly felt a lot slower than it used to be (but I might be wrong). It's so slow (even in 9) that I fear typing a period in JS, however I find that if I always follow the period with a junk char, eg, foo.x typed very quickly, that prevents it from stealing my ability to type for the next 30 seconds. Looks like I'll have to be even more diligent about that if I ever switch to 11.