GNOME Bugzilla – Bug 115072
need to grab mouse clicks in all focus modes
Last modified: 2004-12-22 21:47:04 UTC
The fix for Bug 102209 has made mouse/sloppy client window clicks unnoticed by metacity. We need to at least focus the window on click. If your mouse is over a window, and you alt-tab away, to refocus the window you have to move the mouse out of the window and back in or move the mouse to the frame and click or alt-tab back. A simple click should focus the window. I would say raise and focus -- over the past few days I've tried clicking in a window to raise it probably hundreds of times only to be frustrated. Having to find the frame of the window is just a royal pain.
to fix 102209 but still do this I think you have to use GrabModeAsync/GrabModeSync (whichever one wasn't used before), or something like that. metacity back in the long-ago days used to work that way. The keynav problem is "mouse focus doesn't work with keynav" resurfacing yet again. ;-) Eh, whatever. I am so sick of this raise on click argument that I'm inclined to just /dev/null all of it in any direction. ;-) The only thing I care about is that somebody look into the "don't raise on DND" type of stuff. Which I'm convinced someone will do someday.
Well, I'll make you a deal: I'll just handle all the raise on click stuff. For now since I don't really understand what's going on with the GrabModeA?Sync stuff I just went ahead and made it focus at least on mouse click in sloppy focus. I tried changing to Sync from Async but that didn't seem to do anything. And I tried to get something going on the DnD thing -- no one on wm-spec-list responded to my posting :-(. Maybe I'll try to resurrect it. If we can't agree on anything on wm-spec we might try implement a metacity extension that at least nautilus could implement.
Oh, I misunderstood the bug somewhat (thought it had to do with the "no grab on focused window" thing).
the simplest approach to the DND thing may be a simple WM_PROTOCOLS hint that says "the toolkit will activate the window on click" or "the toolkit will send a client message when it receives a click that should be an activate-click"
the window will focus on click in the client window even in sloppy/mouse mode; it just doesn't raise.
Can I please be contacted when this bug is fixed? It is a huge useability loss for me now that I can't click-to-raise windows while in sloppy focus. It's cutting down my productivity. I don't quite understand why this was pulled, but please, can it get put back in quickly? I can't code, otherwise, I would do my best to submit a patch. Sincerely, occy.
*** Bug 122577 has been marked as a duplicate of this bug. ***
Interesting observation... If you are in the themes tool... [applications, prefs, themes.] If you are in another application, say gnome-terminal, and click anywhere in the theme chooser tool, the click raise works like it's supposed to. Why would it work here, and not in any of the other windows? I just thought this might be something that might help get a fix to this more quickly.
I'm working on the DnD problem, and I don't care about sloppy focus. This is the only open raise-on-click bug listed in rationales.txt. I need to know something. For click-to-focus, why is the behavior raise-on-click instead of raise-on-focus?
Sort of offtopic for this bug, mailing d-d-l is fine for metacity questions btw. Raise on focus might cause some occasional strangeness with apps getting focus for brief moments (currently you wouldn't see this, but with raise on focus you'd get side effects from transient focus in events). Also, you would probably find it created problems with windows that don't really take focus (the ones where we set focus to display->no_focus_window).
On topic: I spent several hours last week trying to fix this bug, and the result is that with current X it is impossible without reintroducing bug #102209. If you have any kind of XGrabButton() you cause the enter/leave events since a grab occurs; if you don't have an XGrabButton() you can't get the button press events. A config option called /apps/metacity/general/115072_or_102209 is not going to happen. ;-) So, I don't really know how to move forward, other than wait for an X extension. Maybe we could try to use Xtest or something.
I once spent some time trying to play with this without any success. But it doesn't seem right that the bug is unavoidable; doesn't e.g. KWin maintain a grab and yet not have that extra enter/leave events bug?
I don't know. If KWin avoids this I'd like to know how it does it.
Yeah, KDE, openbox, and several other windowmanagers allow for this type of behavior. I think it's sad that someone elses bug fix can kill someone elses feature. Also, shouldn't there be a "vote" on it. Like, have a vote on what people, the community, feel is more important. To have one bug fixed or to have another feature removed.
vote all you want; it won't change anything. The extra Enter/Leave events bug is a very serious one. We should take a look at KWin code to see how they handle grabs.
I was simply stating that we should poll users that are affected by this, and see if the cure is actually better than the disease. It's quite annoying to have to hunt down the title bar when you are trying to click a window to bring it into focus. And click to raise doesn't allow you the opportunies that sloppy focus does. This hybrid is the best solution IMHO.
Just my 2c. I used to use the "previous" behavior before I upgraded to Gnome 2.4 (around start of September with 2.4rc1). So, I've been using the "new" behavior since then. All I can say is that I feel it's an *extension* and *improvement* over the previous one. So, while I could look at one window and type in the other even before, now I can look at one window and click in the other. Woohooo, all the better, right? Rare occasions when I need click-to-raise, I use Alt+Click. So, I'm not sure there's even any "correct" solution for this, since I got used to it quite fast (and I actually subscribed to this bug because I wanted old behaviour back at that time ;). Hope this doesn't bring too much fire in here.
With Alt-click I am also enjoying this new behavior. As a conceptual model it may actually be more consistent. Although this is the behavior it sounds like there is more to the underlying bahavior, so I will shut up now.
Chalk another one up in the 'please bring back click-raise' tally. :) I tracked down this bug in bugzilla within *10* minutes of upgrading from Redhat 9 to Fedora Core 1. I am quite addicted to the previous behavior, and agree with a previous commenter that it makes mouse focus kinda pointless. thanks!
I lookup up what KWin, TWM, and fvwm do in in this situation, and they all basically do what metacity does now; i.e. drop the button grab. Now that I really think about it, I've never used an X window manager that would raise on click in sloppy focus once the window was already focused. Sawfish I remember had a "raise and pass through click" that you could bind to a mouse button, but as I recall it would raise all right but not pass through the click. Perhaps this is something that could be added to XFixes?
By default, twm, kwin and fvwm won't raise on click in sloppy focus once the window is already focused. However, all three of the above mentioned window managers makes it available in some form of configurable option. If I remember right, teh default FVWM config files even have examples already in it to do this very thing. KWin has a nice check box to do it. I don't get the resistance to creating a configuration option to do it? It doesn't have to be exposed or even documented. I'd venture to say most sloppy focus users are power users, so figuring out how to configure it is really not a major issue. This is the only feature left that would make me happy to go back to gnome. I'm starting to run into a number of usability issues with regards to KDE as well.
You're missing the point, do those WMs have bug 102209 when the raise on click thing is enabled? If not why not?
You're right. I missed the point of bug 102209. Actually, I completely mis-read 102209. Apparently the button click causes the leave/enter events along with the button press event. I misread it and saw that as a natural behavior of mouse-ing into the window causing the enter event. Completely zoned out the leave event. For a while I was wondering why 102209 was even a bug :). Been quite a while since I've done much non-java code diving, but I'll start taking a look at how sawfish and kwin do this to see if anything makes sense.
I am glad to see someone finally taking a look at this. As a contributor to the free software effort, (in the way of graphics, websites, etc...), it's so hard to have ones hands tied and not being able to fix a bug like this. I'm a graphical guy, I do graphics etc... and couldn't code my way out of a paper bag. That being said though, I am an end-user. I think this type of focus is and was used by tons of people. Lot's of people whom have never found thier way to this bug tracking list. (much like the Close Encounters of the Third kind where only a few people even saw the image of Devil's Tower on TV, and even fewer made it to the mountain). At any rate, I would like to simply re-iterate my opposition to a bug being fixed, rendering, IMHO, a major feature of the windowmanager inoperable. This is just as bad as if Click to Focus, or Sloppy Focus had been left out as a result of fixing this bug. Would the fix still have went through and made it's way into production had one of those other Focus options been rendered non-functional? I know my opinon doesn't count for anything, but at least I've tossed it in the well for what it's worth.
As far as we can tell, the way the code currently is now is the best and only way to do it, because of apparent bugs/limitations in the way XFree86, at least, handles grabs. We've even looked at other WMs, and they all either can't raise on click on sloppy/mouse focus, or have this very serious bug. If someone knows of a way to do both, everyone here would very very much like to hear it. To fix this will in the end require changes to the X server.
Yup, KWin has the same behavior once raise on click is set. I was just doing some testing. I'll buy that this is an X "bug". So every other window manager lives with this problem. Why is it that metacity can't?
This is why: http://bugzilla.gnome.org/showattachment.cgi?attach_id=12228 It breaks a large number of DHTML menus, popups, etc. Basically anything with a mouseOut method that hides a DHTML element will break. People will think that it's a gecko bug.
Neat, I think I'll have to find a "broken" version of metacity to try this with, but with KWin (sloppy focus, click to raise) it will only work if the mozilla window is raised. The initial click forces the raise, then the next click works. Konqueror on the other hand works fine in the background, although the click does also raises the window. Now this makes sense, and explains a number of issues I've had with regards to focus. I guess I know understand the hesitance to enable this as a configuration option. However, it seems that if the rest of the world (other window managers) have to live with the same problem, then why not join the crowd? Then again, I guess this is what makes opensource so great. You guys won't fix it, then I'll just patch my own copy and live with the bug :).
Short term solution... What would be the problem(aside from the fact that I've never compiled metacity before) to simply have a configure option: --enable-sloppy-click And when this option is enabled, simply have it spit out a message at the end saying: If you use this option, your DHTML menu's will NOT work. I personally could care less about dhtml and if it works or not. I much more prefer that my window manager perform in the way I want it to. I cannot upgrade my wifes computer to Fedora, because she uses this form of focus, and Fedora Core has the "broken" metacity in it. (meaning, it has the broken Sloppy/Click to Focus) Havoc, could you please put this in as an option?
*** Bug 128441 has been marked as a duplicate of this bug. ***
*** Bug 127775 has been marked as a duplicate of this bug. ***
Did anyone ever check if other X servers have the extra enter/leave events? Maybe we've been going through all these trials and tribulations over an XFree86 bug?
*** Bug 129048 has been marked as a duplicate of this bug. ***
I think that we need to restore Bug 102209 for now and fix the Enter/Leave events thing in the X server. If someone has access to a non-XFree86 Xserver I would very much like to know if running an old version of metacity has the bug.
*** Bug 129158 has been marked as a duplicate of this bug. ***
*** Bug 129347 has been marked as a duplicate of this bug. ***
Rob: On a Solaris box, still see the problem with the old metacity sources.
so are we satisfied that this is not an XFree86 bug then? That it's the correct behavior for the XServer to send these LeaveNotify/EnterNotify pairs on mouse click in the presence of a grab? This to me just seems plain wrong. Does anyone know where in the X11 standard something like thing would be documented? I'm completely unfamiliar with the standard. To be precise, Arvind, on Solaris you reproduced Bug 102209 using the old metacity sources?
The GrabPointer and UngrabPointer requests both generate EnterNotify and LeaveNotify events. The mode member of the XCrossingEvent structure is set to NotifyGrab for grab-generated events and NotifyUngrab for ungrab-generated events. See the O'Reilly books or the manual pages for XGrabPointer and XCrossingEvent. On Debian, the xspecs package contains: /usr/share/doc/xspecs/proto.html /usr/share/doc/xspecs/proto.ps.gz /usr/share/doc/xspecs/proto.txt.gz which document the protocol. (Same doc, three formats.) I don't recall where those are upstream.
>To be precise, Arvind, on Solaris you reproduced Bug 102209 using the >old metacity sources? Rob: Yes that's correct, on the Solaris Sparc I am able to simulate bug 102209.
Sorry about this stupid question, but I'm just trying to figure something out here. So if Arvind's found that the bug, 102209 on Solaris isn't working with old metacity sources; Shouldn't he try and use the new metacity sources to make sure that the bug is fixed? It seems to me that if the newer, patched metacity, still has the bug present in bug 102209, then the fix didn't work for all systems. Which, wouldn't that in and of itself be a good reason to roll back the fix until we can get a viable solution for all platforms? And fix this bug while doing so. Why can't we simply have a compile-time fix for the 102209 bug? Something like: --enable-dhtml-fix. We could do that in the short term... Anyway, just two more pennies from me.
Trae: It looks like bug 102209 and this bug can't be simultaneously fixed--fixing one would mean breaking the other (and note that using the old metacity sources fixes this bug while the new ones fix 102209). This started to look like an XFree86 bug, but Rob wanted to know if it was specific to XFree86 or whether this was a bug in the specification of the X protocol. In order to find out, he asked Arvind to test on a different X implementation, namely the one on solaris. If you want a compile time fix, just use the old sources (or reverse apply the changes for 102209). There's no point at all in providing a compile time flag which says "--pick-my-poison==bug102209". This bug should be fixed, not left to the end user to workaround. And that's what the maintainers are trying to do. We just need to let them do it.
I wish there were some way to quantify how many people were affected by the old bug 102209 vs. how many people are affected by this new bug. Noone to this point, has answered my main and burning question: Should we allow a new bug to be introduced in order to fix an existing one? Furthermore, should a major feature be allowed to be discontinued due to the fixing of another bug, and as an effect, rendering said major feature unavailable? I think the answer is that unless you can fix both bugs at the same time, you don't go rendering previous features null by fixing another bug. Surely there has to be a way around this, maybe even providing something in gconf-editor or something as a way to work around this bug? Have it as an option in the prefs: [] Enable click to raise [link]read what this feature disables[/link] That way... those that want it, can turn it off, those that don't care about bug 102209 can go on living happily with the feature we want until a fix can be found to make both co-exist and eliminate both bugs. This way, we can all be happy, and the traffic on this bug list can decrease :) I'm sure you all think I'm quite mad, but the lack of this focus method is driving me quite insane. I can't go to another window manager, because they all are quite lacking in what metacity provides. So I'm left stuck here in limbo until this bug is fixed. Thanks again for your time, Sincerely, Trae
We're trying to fix both bugs. We're not going to do an ugly workaround until we're satisfied that there is no choice. Compile time or runtime options as to which bug should appear in metacity is absolutely unacceptable. I'm going to read through the X protocol documentation that Gregory pointed me to and see if I can figure this out. It sounds from his brief description that if we make sure we don't do an UnGrabPointer on mouse click that we won't generate those extra events; whether there's a way to do that and still allow the window to receive the ButtonNotify remains to be seen.
ok... I've said more than enough I guess. I'll keep quiet and let you guys fix things.
*** Bug 129607 has been marked as a duplicate of this bug. ***
*** Bug 126846 has been marked as a duplicate of this bug. ***
*** Bug 130240 has been marked as a duplicate of this bug. ***
Just so that people don't forget or get mislead by reading this bug report... This bug isn't just about windows not-raising upon click; this bug is also about certain panel applets being unusable in mouse/sloppy focus modes. Specifically, applets (such as gdict or the command line applet) which require the user to type cannot be selected/raised/focused by clicking on them which means that the user cannot type into them. There have already been multiple bugs filed about this other sub-issue which have been marked as a duplicate of this one (e.g. bug 129048, bug 129347, and bug 130240). I'm updating GNOMEVER2.3->GNOMEVER2.5, adding the bugsquad keyword, and adding Target 2.6.0. Due to the applet breakage, I really think the priority should be urgent (even if this is a next to impossible to fix bug in light of 102209). But I'll leave it as is for now.
Elijah Newren> Regarding the applet breakage, I am assuming that you are referring to undocked applets (I do not know how to invoke them in this manner). Doesn't Alt+click still work?
I'm using CVS HEAD, and in addition to the applet focus problems already mentioned, I've completely lost the ability to focus my desktop with sloppy focus. I can highlight icons just fine, but I can't rename files because the desktop never receives keyboard input.
As a side note on the "Can't Rename File" thingy... You can switch to a desktop where no apps are open and it'll then allow you to rename. I'm running Fedora Core 1.0 and this bug exists in it as well. This is more of a nasty work-around suggestion than anything.
fixing the summary since it isn't accurate; there are a number of problems caused by this, of which problems focusing the panel and the desktop is just one.
*** Bug 126854 has been marked as a duplicate of this bug. ***
OK I've done some experimentation here. I think that the issue here is in the XAllowEvents call in display.c. Metacity has a button grab, and calls XAllowEvents with ReplayPointer mode. Metacity notably does not call XGrabPointer or XUngrabPointer when a mouse click is made. It also does not call XGrabButton or XUngrabButton on mouse click in a client window, which I mention for completeness since the documentation does not say that these events generate EnterNotify and LeaveNotify events. However, the X protocol and xlib documentation indicate that when XAllowEvents is called with ReplayPointer: For ReplayPointer, if the pointer is actively grabbed by the client and is frozen as the result of an event having been sent to the client (either from the activation of a GrabButton or from a previous AllowEvents with mode SyncPointer but not from a GrabPointer), then the pointer grab is released and that event is completely reprocessed, this time ignoring any passive grabs at or above (towards the root) the grab-window of the grab just released. The request has no effect if the pointer is not grabbed by the client or if the pointer is not frozen as the result of an event. I've read that paragraph a million times and I still don't know exactly what it means. It seems to indicate that it implicitly calls UngrabPointer, and then replays the button/pointer event. However, if this is the case then metacity's grab would have been dropped and it would have to call GrabButton again, which it doesn't. So I then interpret this to mean that it replays the pointer event _ignoring_ the active button grab. The protocol spec, therefore, does not seem to be saying that the server should generate a LeaveNotify/EnterNotify pair on a call to XAllowEvents. So I think that I'm really gonna just have to call this an X server bug, or at least an x protocol specification bug if there's some other more clear version of the spec somewhere. I bet none of the X server developers could figure out what the hell they were supposed to do here and so reverse-engineered the behavior of some existing X server to be compatible. I'm attaching a patch that works correctly under all circumstances for click-to-focus mode by dropping the focus button grab on FocusIn and FocusOut, an restores Bug 102209 for sloppy and mouse focus mode to fix all the problems that dropping the grab has caused, such as not being able to focus the desktop or the panel applets.
Created attachment 22920 [details] [review] the lesser of two evils
That patch looks fine, so we close this bug and reopen the other one (or just close the other one NOTGNOME/WONTFIX or something). Please apply the patch to the stable branch as well. I think what you're missing about the X spec is that the enter/leave happen before we ever call XAllowEvents; they happen as soon as the button press occurs, because the button press implicitly grabs the mouse (same semantics as XGrabPointer()) and when you grab the mouse on one window it causes a leave event on the currently-focused window. So the leave event happens as soon as the button is pressed, on the server side, with no intervention from metacity. The leave event on grab is clearly how X works. Anyway, glad to be rid of this silly bug. Now here comes the bug asking to switch back to not raising on click ;-) Thanks
patch applied to HEAD and to stable branch. What do you think the chances would be for a freedesktop.org-based X extension to fix this correctly?
*** Bug 128835 has been marked as a duplicate of this bug. ***
Correct me if I'm wrong, but I've been monitoring this bug for I don't know how long, now it's stated that it's "fixed", but yet the problem I was wanting fixed isn't really fixed. Is there yet another bug I can monitor for the "Click to focus with Sloppy focus" bug??? Or does this mean that we are simply SOL? *sigh* Trae
Clicking on windows in sloppy focus will now once again focus and raise them. If you want some other behavior, you're probably SOL, since we don't know how to implement any other behavior.
Sorry.... From what I read, the fix was only for the applets that didn't take focus or something else. I apologize... My 3 month old baby daughter was hurt last night and I was quite out of it. I shouldn't read email when I'm all flustered and upset. Thanks guys, and please accept my apologies for not understanding things. Sincerely, Trae McCombs
*** Bug 136333 has been marked as a duplicate of this bug. ***
I just wanted to say something. I understand why you guys must do this but I would still like the sloppy focus to work the way it does on most WMs. I have used the new way since installing 2.6 and it has really cut my production and makes apps such as the gimp hard to use without doing a lot of window cycling. I don't ask you to change what you've done. I don't ask you to to make both an option. This effects a lot of other window managers as well. Would it be possible to make a recommendation on an extension or a patch to XFree86 that would let the "old sloppy focus" method work correctly across all the WMs. If this were done I think they might listen. I don't understand the problem well enough to give even an idea on what they may do to let this work but if you could give me a written recommendation I would personally beat down the doors at XFree86 to get it to them. Thanks for all the hard work. Sincerely Frederick Reeve
Frederick: You weren't very clear about what behavior you really want. You seem to be asking for disabling raise-on-click behavior, which really has nothing at all to do with XFree86 or XOrg. Although a 'fix' for a totally different bug (bug 102209) happened to produce this do-not-raise-on-click behavior as a side effect, it can be obtained without that 'fix'. See bug 115753 for an example patch that produces this behavior.
Thanks. I seem to have to have misunderstood a few things and am not sure I get what all is the problem now even after reading this several times. That is not important though. I thought the fix to make both focus methods work right could only be done in X. At least thats what I thought I got from reading this. I also thought that the fix would be needed to get sloppy working 100% on other WMs as well. You would be correct in saying I want sloppy focus that DOES NOT raise windows on click. The patch did point me in the right direction. It only takes one change to do this in 2.8 a boolean at that. I am very grateful to the author for making it so easy to hack this even though it will not be a config option. In case anyone else is reading this the edit in metacity 2.8 is in display.c line 1384 change TRUE to FALSE. Anyway thanks for info I didn't mean to cause a ruckus.
*** Bug 131152 has been marked as a duplicate of this bug. ***
*** Bug 137253 has been marked as a duplicate of this bug. ***