After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 151996 - Modal dialogs denied focus should probably not be lowered
Modal dialogs denied focus should probably not be lowered
Status: RESOLVED FIXED
Product: metacity
Classification: Other
Component: general
2.8.x
Other Linux
: Normal major
: ---
Assigned To: Metacity maintainers list
Metacity maintainers list
Depends on: 621848
Blocks: 149028
 
 
Reported: 2004-09-06 17:10 UTC by Elijah Newren
Modified: 2010-06-17 03:43 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Correctly handle the case where a transient of the focus window doesn't take focus on map (4.23 KB, patch)
2004-10-23 22:26 UTC, Elijah Newren
accepted-commit_now Details | Review

Description Elijah Newren 2004-09-06 17:10:01 UTC
Just so that I don't forget about this issue...

With focus-stealing-prevention enabled, a modal dialog of an app could be
lowered and hidden behind the main window.  Although there is a
DEMANDS_ATTENTION hint, it would probably be better to not lower such windows. 
In these cases, I'm guessing it would be best to just defocus the main app
(without focusing a different window), and set the DEMANDS_ATTENTION hint.  This
will require a little more work for sloppy and mouse focus, since an EnterNotify
could focus the dialog if it appears where the mouse is.  The METACITY_SENTINEL
should come in handy here, though.
Comment 1 Havoc Pennington 2004-10-03 17:07:36 UTC
Not sure I understand this fully, but the dialog should not be possible to lower
due to stacking constraints. Unfocus yes, lower no.

A simple solution may be that modal dialogs should always steal focus from their
parent app, regardless of focus stealing prevention, since you can't keep typing
in the main app anyhow.
Comment 2 Elijah Newren 2004-10-03 17:49:12 UTC
The purpose of this bug is because of what you say: unfocusing should be
allowed, lowering should not.  This bug is here because I believe Metacity will
currently try to lower a modal dialog--perhaps there is something other code
that will prevent it from getting lowered (I haven't tested this, but wanted to
throw out what I was thinking of so it didn't get lost), but we need to make
sure of that.

I have to disagree with allowing modal dialogs to steal focus.  If the dialog is
an error message, and the default action is to dismiss, then the user can easily
dismiss the window before even realizing that it is there and miss the error
message completely.  This was one of the reasons that we created focus stealing
prevention.
Comment 3 Elijah Newren 2004-10-23 22:26:41 UTC
Created attachment 32978 [details] [review]
Correctly handle the case where a transient of the focus window doesn't take focus on map

Comments on this patch:

It reenables focus stealing prevention.  Perhaps that should have been done
separately, but I needed it on to test it.  I just left it in.	*shrug*

There was a section of code that was overriding the normal rules and attempting
to give transients of focus windows the focus (this would result in windows
being focused more than once, it appears).  It's been there since before focus
stealing prevention, but I don't see why it was needed.  Even if it was, I
think it should have been inside window_takes_focus_on_map() instead.  But it
now gives wrong behavior instead of just duplicating effort, so I have removed
that section.

I'm having second thoughts on the use of METACITY_SENTINEL.  Using it always
results in races, and I believe there's a better way to get the behavior we
want without introducing races.  But I believe it will be a bigger patch, and
so it should be filed as a separate bug.  This patch just uses the sentinel for
now.

This patch will introduce another case where the patch in bug 156251 is
necessary in order to get the starting window of alt-tabbing correct.
Comment 4 Havoc Pennington 2004-10-25 15:35:32 UTC
Comment on attachment 32978 [details] [review]
Correctly handle the case where a transient of the focus window doesn't take focus on map

Seems fine, thanks.
Comment 5 Elijah Newren 2004-10-25 16:30:34 UTC
committed.