GNOME Bugzilla – Bug 129048
Minicommander don't acquire focus if in sloppy mouse mode
Last modified: 2004-12-22 21:47:04 UTC
When gnome is switched in sloppy (focus-follow) mouse, mini-commander applet is not able to get focus when it is clicked. The original focused window catch all characters. How to reproduce from default focus mode: 1) add mini-commander applet to gnome panel a) left click gnome-panel and select "add to panel" -> "Utilities" -> "Mini-commander" b) check that you are able to enter chars in mini-commander applet 2) switch to focus-follow-mouse a) double click "start here" to open "start here" window. b) in this window double click "Desktop preferences" icon to open "Desktop preferences" window. c) in this window locate the "windows" icon (3rh line- 1st column) and double click it to open the "windows parameters" window. d) check the box "select window when mouse is over" to activate focus-follow-mouse mode. 3) check that you are not able anymore to hit chars in the mini-commander applet. NOTE: This bug also occurs in GNOME 2.4 (stable release)
Don't have time at the moment to look at this but from a quick glance it looks like the problem I'm experiencing with the gdict applet (and which I think is due to metacity). Adding myself to cc.
Yes The dictionary applet have the same behavior. Their good chances that every applet having to deal with keyboard focus have the same problem. Metacity must be concerned by this problem as it is the one giving the focus, isn't it ? Perhaps one (using sawfish) could try to check if the same problem exists ...
It's a metacity regression. I updated my cvs installation on another machine and it exhibits the bug. I then went and switched metacity to the METACITY_2_4_34 branch, rebuilt, and restarted metacity and found the bug wasn't there. So, this bug appears to be that panel applets in mouse/sloppy focus (click-to-focus mode doesn't have a problem) do not obtain focus when clicked on. (In desktop 1 on Fedora, I can get the applet to have focus by clicking on it and then by hitting Ctrl-Alt-Tab, but for some reason that doesn't work on the other virtual desktops).
*** This bug has been marked as a duplicate of 115072 ***
I was afraid this bug might be a duplicate of that one...I spent several hours once trying to figure out how to fix that bug. And apparently the consensus is coming to the fact that it's an XFree86 bug (which I don't have any hope of trying to fix). Thanks for the quick response, Rob.
The click + Ctrl-Alt-Tab workaround for Fedora on Desktop 1 runs well for me on all desktops (a "Top panel" icons appears in the cycle selection list: metacity 2.6.3 - gnome 2.4.1). Would you explain a bit in what this bug and bugs #102209/#115072 are related ? I understand well the laters but not the relationship with this bug.
Here's my understanding (probably not quite correct, but it's the general idea): Bug 102209 was noticing that metacity was sending extra events to programs upon clicking and that those extra events broke certain applications (e.g. Mozilla). The bug was fixed and people noticed that it changed certain behaviors (i.e. windows no longer raised on click in sloppy/mouse focus). They decided to stick with that new behavior for a little while, but then noticed in bug 115072 that since those extra events had been removed, it was difficult to have windows raise on click in those modes and have bug 102209 be fixed. While raising windows and focusing applets may not seem related, it is those extra events upon clicking that allow the applets to obtain focus and get the mouse cursor so you can actually type in them.