Hi, Denis. Thank you for review, see my comments inline.
the fix conceals other scenarios. Now if another fix breaks the activeWindow field logic it can be unnoticed. Do not you think it is worth to distinguish the field update on per-AppContext basis instead?
The activeWindow field logic is a global thing, only one window can be active even if we have multiple appcontexts. We have two accessors to this field: - KeyboardFocusManager.getActiveWindow(): which returns the active window if it has the same context as a caller. - KeyboardFocusManager.getGlobalActiveWindow(): which returns the active window as is. In the current fix, the "getGlobalActiveWindow" is used intentionally. If one window in one appcontext: - became an active, or - lose the focus to nowhere, then it should try to send WINDOW_DEACTIVATED to the previous active window, even if the previous window is located in another appcontext. Note that WINDOW_DEACTIVATED does not mean that current active window will change, because in the moment this event will be posted/dispatched the current active window might be changed by another EDT, for this case we have a check [1], we will reset the field only if the active window was not changed. [1] http://hg.openjdk.java.net/jdk/jdk/file/ad9077f044be/src/java.desktop/share/classes/java/awt/DefaultKeyboardFocusManager.java#l736 -- Best regards, Sergey.
