All the parent's OS widgets are still active. So you can still get to the menus, resize the window, and -- this is probably bad -- close the parent window. That was the subject of a recent bug on the Windows build. And any other browser window you may have up is still completely active (which is how Windows behaves, so as long as that makes sense on Linux, too, I can't complain.)

Is this truly X/Gtk+ issue, or are we seeing the problem on Windows too? Two weeks ago when I re-did modality I basically took the windows sources and at the time believe I achieved parity.

Awwww yeah. It's Gtk-specific. This is an area where code that looks the same doesn't necessarily give the same results. Modality is achieved on Windows by deactivating the parent window using an OS call. It's done completely differently on the Macintosh. It's not too surprising that neither solution quite works on Gtk.

O.k., now that I have taken the time to test it, we have a parity problem. I am looking into it. I think the problem can be fixed by checking the event x,y coords to see if the event is in the rect of the window that is modal. A problem here is that Gtk/Gdk is discarding the x, y information for keypresses (this is supplied by X by gdk thinks it is helping you by discarding it. argggg.)

Lack of true modal dialogs is a general problem on all platforms. This seems to be the closest bug for that issue, though I'm not sure if it is assigned to the right person. Should we change this to cover the general issue? (We need a bug number to use in "depends on" field in related bugs.)

Added SetModal interface to nsIWidget; platforms can call whatever they like from there in order to make a window truly modal.

Marking bug fixed.

ummm, check out bug 6816. i think the last modality problem is addressed there. i'm going out on a limb and calling this verified.