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.
I noticed a strange thing with today's build - if focus is in the editor or Explorer, and I click on the property sheet, the following happens: - The property sheet gets focus - The Properties title bar turns blue to indicate the component - Focus is immediately shifted back to the editor or Explorer So I end up with the property sheet being the activated top component and focus in the editor. Clicking on the property sheet a second time works (I guess because winsys already thinks it's activated). I dug through the PropertySheet code, commenting things out, and found it wasn't my problem. Finally I patched java.awt.Component to log calls to requestFocus(). The following line is calling requestFocus() on the component that had focus *before* the property sheet: org.netbeans.core.windows.view.ViewHierarchy.upda teViewHierarchy(ViewHierar chy.java:121) I will attach the log from the patched Component class.
Created attachment 12563 [details] Stack traces from java.awt.Component.requestFocusHelper()
Possibly related - the popup text box in explorer is also not working correctly - start to type and one character goes to it, then it disappears...most of the time. Sometimes after repeated clicking it works.
I mean the helper popup JTextField that pops up if you just type in Explorer and helps to find a node name you typed.
This may be a duplicate of issue 37995.
Yes, the stack from requestFocusHelper, points to the same cause like I came in issue #37995 (ViewHierarchy.udpateViewHierarchy). I hope it is same. Now it seems I can remove that hack thank to fix of issue #37756. But first I'm going to check that.
Fixed in [trunk] core/windows/../view/ViewHierarchy.java 1.8 /ui/MainWindow.java 1.7 Note: This doesn't fix the other issue. The problem of this was a hack which preserved focus in view GUI hierarchy..., there is a case when some component has focus, and is removed/added back, because its parent split is removing due to a sibling close), the focus is lost, thus needs to be restored. Originaly the hack was too aggressive it restored the focus in all cases, now it does it only in the above described case, which excludes all cases like this issue describes.
verified in [nb_dev](200402221900)