On Thu, Jan 29, 2004 at 08:29:19AM +0200, Tuomo Valkonen wrote: > We can't fix every single broken program with Ion kludges. If Ion indicates > some window having the focus, and frame operations work correctly within > that frame, then the key presses _must_ be going to the correct (main) > window, and Mozilla/XUL/GTK is just _seriously_ brain-damaged, trying to > keep itself track of focus instead of letting X do it.
I finally managed to get Mozilla in this mode, and the case indeed seems to be either this, or that Mozilla is no handling the WM_TAKE_FOCUS message correctly[*]. Menu accelerators (Alt+underlined letter) still work correctly, so at least the correct main window really does have the focus. More often than keys being handled in the wrong window, the keys just are not handled at all, and this would suggest Mozilla not taking action upon receiving WM_TAKE_FOCUS. The fact that sometimes the wrong location bar gets the keys would, however, suggest that it were doing all sub-window focus management on client side and occasionally getting confused when the window is switched. Bugzilla seems to be full of focus problem reports, but I couldn't find exactly this one with a quick glance... I still have not managed to confuse Firebird (0.7). [*] The ICCCM specifies that if applications want to focus subwindows (e.g. text input boxes) of top-level windows, they should indicate in the WM_PROCOLS atom that they support the WM_TAKE_FOCUS message. The window manager should then send this message to the top-level window when it would be focused and the client window is only then allowed to set focus to one of the subwindows. Unfortunately the ICCCM doesn't specify at which point and with what timestamp the window manager should set "fallback" focus to the top-level window. Different WM:s seem to do this differently, and e.g. Eclipse used to not like the way Ion used did this until 2004-05-24. -- Tuomo
