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. ***