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.
After clean NB install, no plugins. WinXP config'd for X-Mouse using PowerToys > Tweak UI > Mouse > X-Mouse (activationFollowsMouse=YES, Autoraise=NO) - Start NB - Move mouse to other app, e.g. a browser Observe that the NB editor cursor in stops blinking - hit some keys while mouse is over other app - Move mouse over NB Observe that NB editor cursor starts blinking - hit some keys, e.g. cursor movement keys Observe that keys are delivered to previously active/focused window Note: jdk6 works correctly Note: also fails with NB-7.2 (autohide taskbar doesn't matter) Product Version: NetBeans IDE 7.3 Beta 2 (Build 201211062253) Updates: NetBeans IDE is updated to version , NetBeans 7.3 Beta 2 Java: 1.7.0_10; Java HotSpot(TM) Client VM 23.6-b04 Runtime: Java(TM) SE Runtime Environment 1.7.0_10-b18 System: Windows XP version 5.1 running on x86; Cp1252; en_US (nb)
Please run some plain Swing app, e.g. SwingSet demo with the same JDK and reopen if the problem is not reproducible in that app, thanks.
SwingSet2 works as expected. BTW, though different, this is reminiscent of Bug 175809 (which does not depend on jdk) where key events get delivered to the editor, but the undo/redo buttons are not enabled.
I work with a single screen and sometimes want to refer to a window on top of NB while I am focused/typing into NB. With this bug there is no way to do that since I must mouse click on NB and that raises the NB window. Here's a further observation on the behavior I see: When the mouse moves from the other app to NB, NB's taskbar icon starts blinking. This blinking is typically the behavior I see when a modal dialog pops up.
Soon there will be no workaround for this issue, since jdk7 is becoming required; bumping back to P3. This greatly interferes with my workflow. When the mouse comes back to the NetBeans frame, the taskbar unhides and the NetBeans task icon highlights. It is as though XP thinks NB has made a modal request (or something like that). With other apps, when the task icon highlights this way, all that is required is to mouse over the app, this doesn't work with NB since a click is required. Where is the likely code that is responsible for this issue? If I can find time, I'd like to take a look. (Much better for me to explore a fix now, rather than get a bug report against 7.4 and being unable to work efficiently.) (I wonder if this happens on more recent window platforms?)
Try debugging TopComponent.requestFocus() and TopComponent.requestFocusInWindow() methods. Also can you reproduce that behavior with other windows than code editors?
> can you reproduce that behavior with other windows than code editors? Yes - The welcome window on startup with a clean userdir/cachdir. - When focus is in the projects TC with no editor open.
(In reply to comment #5) > Try debugging TopComponent.requestFocus() and > TopComponent.requestFocusInWindow() methods. The behavior "the taskbar unhides and the NetBeans task icon highlights" occurs when the mouse is moved over the *titlebar* of NB's Frame (not over any netbeans window/component). The method InputListener.mouseEntered is not triggered. The methods requestFocus* are never triggered. I think that because the NB entry in the taskbar is blinking, that no events are delivered to NB until the Frame is clicked. I can't tell if an event is posted to Java's eventQ when the mouse enters the taskbar. I don't know how to ignore all the timer events.
I put a breakpoint in DefaultKeyboardFocusManager::dispatchEvent and when the mouse is moved into the Frame there is ACTIVATION then WINDOW_GAINED_FOCUS events. It's unclear to me what should be happening with these...
I'm out of ideas... Can you try a simple platform application to see if the problem is reproducible there? And how about when a modal dialog window is showing, e.g. Open Project?
> Can you try a simple platform application to see if the problem is reproducible > there? Is there an example/source of a minimal platform app kicking around?
(In reply to comment #10) > > Can you try a simple platform application to see if the problem is reproducible > > there? > > Is there an example/source of a minimal platform app kicking around? Just use the New Project wizard to create 'NetBeans Platform Application'. (You may need to activate NetBeans Plugin Development in Tools - Plugins - Installed.)
Looks like this is a generic java7 issue; my earlier test must have been flawed, because SwingSet2 also exhibits the problem. The "Troubleshooting Guide for Java SE 7 Desktop Technologies" has a section on "Problems with Focus", including "Focus Models Supported by X Window Managers" http://docs.oracle.com/javase/7/docs/webnotes/tsg/TSG-Desktop/html/awt.html#gcwun which says that focus-follows-mouse mode is not detected by xawt; Windows also I guess. It suggests a workaround 'MouseListener on the window and request focus on it when mouse crosses the window borders", so I may play with this. Maybe build a module with a boolean option. I'm not sure a 3rd party module can provide a general NB solution, because need to discover new windows when stuff is undocked.
Further reading of the troubleshooting guide suggests that there should *not* be a problem with Frames, only with Windows.
Closing as wontfix as there's no code to react to mouse-over in IDE title bar. Possibly also related to JDK bug #9001180 (which isn't public at the moment).
> Possibly also related to JDK bug #9001180 (which isn't public at the moment). Yes, I filed that on March 29. After filing I got email would be available as http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9001180 in a few days. Do you have any insight on this private/public thing and what that means about the status of the bug?
(In reply to err from comment #15) > > Possibly also related to JDK bug #9001180 (which isn't public at the moment). > > Yes, I filed that on March 29. After filing I got email would be available > as http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=9001180 in a few days. > Do you have any insight on this private/public thing and what that means > about the status of the bug? I can see the private bug report but there was no activity on that bug since it has been filed.