I'm pretty sure I've never seen a WM that behaves like this (under
Linux) so I can't really class this as a bug. That said... it seems
like it would be a really sane/good behavior. [Might be misrembering
other WM's behaviors, of course, but I've checked with sawfish and
this does not appear to be the case.]

I wonder how this interacts with keyboard navigation; for example 
if I'm using the mouse I might be able to click the close button on
the parent window of the modal dialog, but if I'm doing keynav I would
only be able to close the window if I can focus it.

Created attachment 10001 [details] [review]
grab system modal dialog

Havoc, did you have any chance to look at this patch!

This one definitely needs a lot of detail from UI guys on 
how it's supposed to work, before putting in the feature.

Havoc, can you please tell who are those UI guys ... and shall we add
cc to them to start it.

they are already cc'd, usability-maint

I think bala's concerns are correct... the whole point of making a
window modal is that you can't interact with any other windows until
you've dealt with it.  If you can close its parent window while its
open, who knows what sort of unstable state you might leave the system
in (especially with system modal dialogs, although nobody should be
using those).

Ah, hang on though, I see why the current behaviour is more or less
correct, now, for app-modal dialogs at least... you wouldn't be able
to minimize an app until you'd dismissed its app-modal dialog, which
would be rather annoying.  For system modal dialogs, though, that
would probably be a good thing.

So, I think the only 'problem' here is that you can focus the parent
window while it has an app-modal window is open, even though it's
totally non-interactive.  Is there any way to keep the focus on the
app-modal child even if you click in the parent window?  (Whilst
keeping the parent window's maximize and minimize buttons active?)

Calum two questions here - 
 - for app modal dialog I agree 100% of course you shouldn't 
   be able to focus other windows in the app
 - for system modal dialog, we have no such concept at the moment
   so I'm asking a higher-level question about whether to add
   one and when to use it and how it behaves

We don't have a concept of a system modal dialog?  What are all the
references to SYSTEM_MODAL hints in JeyaSudha's patch then?  I'm
confused... :/

SYSTEM_MODAL in the patch is an old Motif hint that nothing much
really uses, AFAIK. No window managers other than mwm/dtwm have every
supported it to my knowledge. I don't personally have a clue what this
hint is supposed to do when set, or whether it makes sense for GNOME
to support it.

I assume all it's supposed to do is disallow interaction with any
other window on the destkop until you've dismissed it-- kind of like
the Logout dialog, which is about the only time I've ever seen a
system modal dialog legitimately used.

I guess support would only be useful if somebody was running a Motif
app under GNOME that happened to need it.  However, using system modal
dialogs is pretty bad form (according to both the Motif Style Guide
and the HIG), so I don't think this is an urgent requirement.

#92102 says this is in sun-patches; I think it would be kind of a
dubious idea to put this in Sun metacity without putting it in
mainline, because there are too many possible interactions with other
apps, the wm spec, and with the internals of metacity. i.e. this patch
will break often.

I'm not saying I'll be upset if you put it in the Sun patches, it's up
to you to make the call, I'm just saying it's the sort of thing I
wouldn't put in Red Hat specific patches because I'd expect it to
cause me pain.

Created attachment 10844 [details] [review]
Recreated the patch

Agree with Havoc - I can see this causing a world of agro. It seems
similar to how windows behaves (and I dont like it)

For example if you have an app that respawns (eg: nautilus) then you
would probably need to logout to carry on working if a problem came up

Doing this via XGrabPointer() seems pretty unrobust to me. 
I might just refuse to focus any other windows, and not pass through
clicks to other windows, or something like that...

But I don't know, it'd take some experimentation, and we don't even
know if we want the feature - it's not covered in the HIG.

The reason system modal dialogs aren't covered in the HIG is because
no app should ever use them except in the direst of circumstances...
actually I think the HIG does say *that*, but nothing else :)  

Even for the usual "this app has died" case, an app-modal dialog is
usually the order of the day, unless there's a consequent risk of
damaging/losing data in some other application if you were to continue
using that other application.  On a memory-managed, multitasking
system, this is, hopefully, very unlikely to ever happen :)

So:

 - this really hard to figure out how to implement, current 
   patch has issues
 - we have no definition of what behavior we would 
   ideally have if it were implemented (what happens 
   if you click various places, what guarantees we make 
   to the app)
 - there is no standard window manager hint for it
 - the HIG says to never (or basically never) use the feature
 - if the app just wants a pointer grab, it can do that itself, 
   with no window manager assistance; and that's all the 
   current implementation does

Closing bug since the implementation code is broken and I don't 
see how to make it not broken, and the usability team thinks 
the feature is a bad idea. Which leaves us with "why the heck 
is it in sun-patches?" but not my problem. ;-)