Created attachment 135863 [details]
stacktrace

*** Bug 231321 has been marked as a duplicate of this bug. ***

From offline discussion with the reporter:

The problem occurs when invoking rename using the keyboard shortcut. When rename is started, the focus remains in the editor and typed in characters corrupt the code.


The same thing happens when using goto-type from the editor using the keyboard shortcut.

This bug already has 5 duplicates 
see http://statistics.netbeans.org/exceptions/detail.do?id=201462

Created attachment 141096 [details]
stacktrace

1. Create 2 simple classes in same package:

------------------------

package Rename;

public class ClassA {
    public ClassA(int i) { }
    public void method(){ }
}

------------------------

package Rename;

public class ClassB {
    public ClassB() { }
    public void m1(){
        ClassA a = new ClassA(10);
        a.method();
    }
}

------------------------

2. Open Classb and put carret on "me|thod"  (where '|' is position of carret)

3. By Ctrl+R invoke Rename dialog

4. Type new name and press Refactor

>> you'll get this exception

I'm observing this bug about half of the time when invoking "Find Usages" with the keyboard shortcut (Ctrl+F7, then Enter to close the resulting dialog box) when the cursor is on a Java identifier in the editor. Once the bug happens, it will happen every time the Find Usages dialog is opened again with the same procedure (without making other changes to the UI state). Command+Tab'ing to a different application and back again to NetBeans gives the bug another ~50% chance of disappearing or reappearing.

Hmm, I'm not actually seeing an exception, however. But I am definitively observing behavior where the "Editor steels focus from modal dialog"--pressing Enter in the "Find Usages" dialog will actually insert a line at the cursor location in the editor behind the dialog box. Would this be a different bug?

(In reply to ebakke from comment #7)
> Hmm, I'm not actually seeing an exception, however. But I am definitively
> observing behavior where the "Editor steels focus from modal
> dialog"--pressing Enter in the "Find Usages" dialog will actually insert a
> line at the cursor location in the editor behind the dialog box. Would this
> be a different bug?

I can reproduce it, but it does not always happen. Sometimes the focus is still in the editor even with the modal dialog opened. F.e. the caret blinks, the arrow keys work and you could type other keys.

Product Version: NetBeans IDE 8.0 (Build 201403101706)
Updates: Updates available to version , NetBeans 8.0 Patch 1
Java: 1.8.0_05; Java HotSpot(TM) 64-Bit Server VM 25.5-b02
Runtime: Java(TM) SE Runtime Environment 1.8.0_05-b13
System: Windows 7 version 6.1 running on amd64; Cp1252; en_US (nb)
User directory: C:\Users\markiewb\AppData\Roaming\NetBeans\8.0
Cache directory: C:\Users\markiewb\AppData\Local\NetBeans\Cache\8.0

Changing to P2 so that it will be looked at for 8.0.1.

Mila can you please look at this Bug. Thank you

I went through all the Component.requestFocus() in editor and selected some of them which possibly could be eliminated others could be replaced by requestFocusInWindow(). I'll apply the diff after the release to not destabilize it. Anyway that is not a culprit of this issue very likely.

Luckily Standa said that he's able to reproduce the problem on its Mac occasionally so I've added him to cc.

It seems that the trigger is this JDK bug: https://bugs.openjdk.java.net/browse/JDK-8023148

Under some circumstance the focus manager throws a NoSuchElementException which breaks the focus transfer flow and a modal dialog can open while having input focus still in the editor window.

The problem is reproducible only when assertions are turned off because otherwise NetBeans Report Exception window pops up and restores the focus.

The JDK issue is a P4 only at the moment so we may want to escalate it and/or try to find some workaround on our side.

*** Bug 244137 has been marked as a duplicate of this bug. ***

Thanks Stando.
I went through the exception reports' logs and I found a similar problem when EDT goes through focus manager:

...
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1954)
java.awt.DefaultKeyboardFocusManager.dispatchKeyEvent(DefaultKeyboardFocusManager.java:806)
java.awt.DefaultKeyboardFocusManager.preDispatchKeyEvent(DefaultKeyboardFocusManager.java:1074)
java.awt.DefaultKeyboardFocusManager.typeAheadAssertions(DefaultKeyboardFocusManager.java:945)
java.awt.DefaultKeyboardFocusManager.dispatchEvent(DefaultKeyboardFocusManager.java:771)
...

but ends up with an exception e.g. NPE or others (from javac):

java.lang.NullPointerException: selected
org.netbeans.modules.refactoring.java.ui.RenameRefactoringUI.create(RenameRefactoringUI.java:446)
org.netbeans.modules.refactoring.java.ui.ContextAnalyzer$1.createRefactoringUI(ContextAnalyzer.java:117)

It seems that it breaks the focus manager from functioning normally. IMHO the focus manager should made more robust to handle these cases well - hopefully a JDK issue will handle that.
On the other hand we should attempt to eliminate our exceptions too so reassigning to refactoring to possibly avoid the NPE in RenameRefactoringUI.

(In reply to Miloslav Metelka from comment #14)
> It seems that it breaks the focus manager from functioning normally. IMHO
> the focus manager should made more robust to handle these cases well -
> hopefully a JDK issue will handle that.
> On the other hand we should attempt to eliminate our exceptions too so
> reassigning to refactoring to possibly avoid the NPE in RenameRefactoringUI.

I do not understand how you come to this conclusion. Editor is stealing focus from a modal dialog which causes these exceptions to occur, how and why should this be worked around in refactoring? The same problem happens when using Go-To and probably others ...

Please reevaluate if there is nothing that the editor can do, or reassign to JDK if this is a JDK problem.

Ralph, me and Standa suspect that if the dispatching of focus related events from a focus manager fails with an exception then the focus system gets disrupted in a way the users see i.e. the focus stays in editor instead of the modal dialog.

Please click "Exception Report" link and e.g. report 696240 and open its Messages Log and search for "focus". You'll find a NPE starting with

java.lang.NullPointerException: selected
	at org.netbeans.modules.refactoring.java.ui.RenameRefactoringUI.create(RenameRefactoringUI.java:446)


being called from

...
java.awt.KeyboardFocusManager.redispatchEvent(KeyboardFocusManager.java:1895)
...

i.e. the event dispatching process in the focus manager does not finish due to that NPE. Could you please eliminate the NPE throwing from the refactoring UI to see whether this resolves the focus problem?
Thanks.

*** Bug 246762 has been marked as a duplicate of this bug. ***

*** Bug 247080 has been marked as a duplicate of this bug. ***

Issue got lost as it was assigned to Milutin (Mito, you are not working on this right?)

Coming back to the issue, I'm unable to reproduce with current version of jdk.
java version "1.8.0_31"
Java(TM) SE Runtime Environment (build 1.8.0_31-b13)
Java HotSpot(TM) 64-Bit Server VM (build 25.31-b07, mixed mode)

Looks to be fixed by:
https://bugs.openjdk.java.net/browse/JDK-8013611

I am not working on this, thank you for closing this one Ralph