This looks like damage from superwin's change of GtkWidgets to GtkObjects. Among other things, dependent windows are never made transient (see the end of nsWindow::CreateNative) because a GTK_IS_WIDGET check is failing.

Pav, you're gonna hafta triage this one, cuz I dunno from GtkObjects

Is this bug: modal dialogs aren't in front of other windows? If so, we should up the priority here.

Yup. This bug means that modal windows won't force themselves in front of the window they're modal to. The user can trivially switch back and forth between them.

*** Bug 27117 has been marked as a duplicate of this bug. ***

spam: added self to cc list.

some work was done with bug 27117 -- danm's suggestion of removing ~/.mozilla/profilename/localstore.rdf seemed to fix the symptoms of bug 27117, though it likely isn't a long-term solution. :) Thanks :)

Does this bug overlap with bug 19221, "Dialog Modality added for Bug 10000 causes bad UE bustage"? The problem noted here seems not to be a problem on WinNT using 2000-03-01-08-M15 for any modal dialog I found to try - they are modal to their parent window as expected.

This bug is still present in my nightly (3/31/00) CVS build. Added myself to cc.

Mass-moving most M15 bugs to M16

dan -- i've fixed the gtk code to make the windows transient. when creating a dialog I don't get a parent passed in to me so it doesn't get made transient. Could you look at this?

moving to m18

mass-moving all bugs to m21 that are not dofood+, or nsbeta2+

Recent builds on Linux have had wonderfully modal windows, if modal windows can be wonderful. Some unnamed benefactor must have snuck a fix in.

mass-verifying WorksForMe bugs which haven't changed since 2001.12.31. set your search string in mail to "EmperorLondoMollari" to filter out these messages.