Red Hat Bugzilla – Bug 100526
window click doesn't rase window
Last modified: 2014-01-21 17:48:42 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030703
Description of problem:
When window focus is set to "Select windows when the mouse moves over them" the
window will no longer be brought to the from if you click on it, you have to
click on the window border or title. The behavior is the same when "Raise
selected windows after an interval" is selected. When neither of the above are
selected you can click on a window and it will come to the front. The behavior
should at least be consistent throughout the different options. Personaly I
would prefer that clicking on a window will always bring it to the front.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. turn on "Select windows when the mouse moves over them"
2. open two windows that overlap
3. click on the window in the back
Actual Results: When "Select windows when the mouse moves over them" is
selected the window does not come to front unless the window border or title is
clicked on and when it is not selected the window comes to the front wherever
you click on it.
Expected Results: The window should either be brought to the front or stay
there, but it should at least be consistent throughout the different selections.
Confirmed here as well.
I was told by blizzard that this behavior is intentional in order to overcome
some problem affecting mozilla. Is this correct?
From a user standpoint I think click-window-to-raise is the most common behavior
on any platform I've ever worked on and the current behavior of metacity in the
beta would be horribly intimidating to the user, old or new.
The way metacity intercepted clicks caused a spurious leave/enter event
sequence that confused mozilla and also some other apps. It was
genuinely kind of broken in metacity.
To fix this I stopped intercepting clicks on the focused window.
This has no visible effect in click to focus mode since the focused
window is always raised, but changed the behavior for mouse focus
since it's hard to click a window without focusing it.
I didn't really mean to change that at the time but had been thinking of
changing the raise-on-click behavior for mouse focus anyhow so just left it for
now to see whether the complaints exceeded the number of complaints I had
for the previous behavior...
It could be fixed without regressing mozilla, but you'd have to rearrange some
code in metacity to intercept clicks again on the focused window, but this time
without freezing the mouse device on the intercept (the mouse device was frozen
in order to allow "don't pass through click" mode, i.e. to give the
option of eating the click).
So, there's some code to be written to address this. I don't know exactly
how hard it is, probably not that bad.
I don't really know whether mouse focus should raise on click or not,
despite reading thousands of lines of commentary on the topic. I was most
recently leaning toward "not raising on click with mouse focus are the
traditional unix behavior and the way metacity originally worked."
I just use click to focus myself, though I used mouse focus for a few years
back in the day.
I do absolutely share Seth Vidal's point of view. The new behaviour is
absolutely counterintuitive compared to the previous one. Depending on the theme
it may become very difficult to click on the frame, and being forced to move to
the title bar is really cumbersome.
People probably don't want to spend time arguing the merits here,
I've already read a few thousand lines on the subject and had people
tell me about it in person and so forth...
There are several bugs in gnome bugzilla with long threads about it...
Basically it's been discussed to death, all I can think of that could be added
at this point would be a real usability study with video cameras and timers and
If there has been so much discussion about this wouldn't that lead you to
believe that this behavior is receiving a large number of complaints? So has the
number of complaints exceeded the number of complaints about the mozilla
problem? That was your criteria for returning this functionality to its previous
Alternatively, since this is a workaround implementation for a bug in metacity
to only work better with mozilla it might be consistent with other the other
'workaround' options in metacity to give a 'disable fix for mozilla' option in
Then I can turn off this fix and live with the mozilla bug.
I would have to agree with Seth here. It would be nice to at least have a way to
change this in gconf.
Moved to http://bugzilla.gnome.org/show_bug.cgi?id=115072