Bug 100526 - window click doesn't rase window
Summary: window click doesn't rase window
Alias: None
Product: Red Hat Linux Beta
Classification: Retired
Component: metacity   
(Show other bugs)
Version: beta1
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Havoc Pennington
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2003-07-23 05:57 UTC by Elliot Peele
Modified: 2014-01-21 22:48 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2003-10-03 22:19:31 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Elliot Peele 2003-07-23 05:57:33 UTC
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):

How reproducible:

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.

Additional info:

Comment 1 Seth Vidal 2003-07-23 23:43:23 UTC
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.

Comment 2 Havoc Pennington 2003-07-24 04:29:32 UTC
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.

Comment 3 Joachim Frieben 2003-07-26 21:54:43 UTC
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.

Comment 4 Havoc Pennington 2003-07-27 23:51:42 UTC
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 
such. ;-)

Comment 5 Seth Vidal 2003-08-02 05:46:58 UTC
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.

Comment 6 Elliot Peele 2003-08-02 05:56:45 UTC
I would have to agree with Seth here. It would be nice to at least have a way to
change this in gconf.

Comment 7 Havoc Pennington 2003-10-03 22:19:31 UTC
Moved to http://bugzilla.gnome.org/show_bug.cgi?id=115072

Note You need to log in before you can comment on or make changes to this bug.