25684 - [crash] modal windows/dialogs are not 100% modal

Status: VERIFIED WORKSFORME

(Core :: XUL, defect, P2)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

In 4.x, a modal window (e.g. alert(), prefwindow, etc) would be completely 
modal, i.e. the dialog would always stay in front and could not be moved to the 
back. This is not the case in Mozilla, e.g. try this on windows:

Tasks->My Wallet->Change Password...

modal dialog appears. switch to another open window
switch back to mozilla

the dialog is gone. "did it go away? okay, I guess I can continue browsing.. but 
 wait, none of the UI responds to mouse movement or clicks..."

minimise all windows. the modal dialog is still there, behind all the others. 

Expected behaviour:

modal dialogs should always remain on top of the window that spawned them 
(note that distinction) and not allow themselves to be pushed back.

I tried javascript:alert() in the urlbar and this seems to function properly.

Comment 1

[Peter Trudelle]

reassigning to danm as p2 for m16

Comment 2

[Peter Trudelle]

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

Comment 3

[Ben Goodger (use ben at mozilla dot org for email)]

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

Comment 4

[Stephen P. Morse]

I believe this has been fixed with checkins made over the past few weeks.  At 
least all the dialogs that I'm tracking (wallet/single-signon/cookies) all 
appear to be modal now whereas they weren't before.  So this probably can be 
closed.  However I don't know about other dialogs so I'll leave it to someone 
with a more global view to close the repot.

Comment 5

[Stephen P. Morse]

Oops, I spoke to soon.  Just checked on the dialog asking for master password 
and it is not modal.  Bug still exists.

Comment 6

[Dan M]

  Windows that still don't behave modally at this point are (1) on Linux, all 
windows (see bug 19255) and (2) on NT, any modal dialog whose parent window is 
the Hidden Window. (The wallet dialogs, among many others, use the 
nsNetSupportDialog service, which uses Hidden Window). Without a real parent 
window, it's tough to figure out which browser to make the modal window modal to.
  No handy solution readily presents itself.

Comment 7

[Stephen P. Morse]

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

Comment 8

[Stephen P. Morse]

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

Comment 9

[Stephen P. Morse]

The last two bugs that were marked dups of this one (bug 28706 and bug 31647) 
were both crashing bugs.  So is there any chance of raising the priority on this 
one and get it in for M15?

Comment 10

[Dan M]

The fix for bug 27048 will allow dialogs thrown up while networking to use the 
right window as the modal window's parent, rather than HiddenWindow. That's all 
that's necessary to get modal behaviour out of the windows which still misbehave. 
So I think this will be relatively easy to fix once we have 27048, but we are 
very dependent on that.

Comment 11

[Stephen P. Morse]

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

Comment 12

[Peter Trudelle]

Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2

Comment 13

[Paul MacQuiddy]

spam, open xptoolkit qa contact moving over to jrgm

Comment 14

[Stephen P. Morse]

In certain scenerios (as presented in some of the dupes of this report), this 
bug can lead to a crash.

Comment 15

[leger]

Adding crash keyword.

Comment 16

[leger]

Putting on [nsbeta2+] radar.  

Comment 17

[Stephen P. Morse]

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

Comment 18

[Sean Richardson]

Just restarted WinNT after doing almost nothing with Mozilla in that NT session 
except test bug 41670, the latest DUP here, and was prompted twice to [End Task] 
for NSPR:EVENTRECEIVER ... the crash detailed in 41670 may be leaving NSPR 
around.

Comment 19

[Dan M]

  Been looking at this. The problem is, there are many modal windows in the 
product that don't have proper parent windows. So they use HiddenWindow, and then 
they're only half modal. This happens in ... I'll guess and say a hundred places. 
Could be.
  I have under review now some changes that allow people to extract the correct 
parent window from properly initialized channels. That should be checked in soon. 
It will clear up some nontrivial fraction of the flavors of this bug covered by 
(duplicate) bug 41670. The only problem I know of that will remain after that 
will be another 99 places where it's not obvious how to properly initialize these 
channels. Networking guys, beware. This bug's gonna be yours.

Comment 20

[Dan M]

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

Comment 21

[Dan M]

  I've just added 16 bugs pointing out where modal dialogs are created without a 
proper parent (using HiddenWindow instead). This bug will be magically better 
once those places have all been cleaned up. Adding dependencies. This alone may 
not fix this bug, depending on the method used to fix those 16 bugs by their 
unlucky recipients. (I'm thinking that necko channel objects will often be used 
as solutions in The Sixteen, since they often carry nsIPrompts around. But not as 
often as they could; those channel objects will probably need to be more 
aggressively given nsIPrompt objects.)

Comment 22

[Dan M]

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

Comment 23

[Dan M]

  Yes, as fixes for the dependent bugs in the 441xx range begin to roll in, it 
becomes apparent that even once all those are fixed, this bug won't be fixed 
until more channels are given nsIPrompt windows when initialized.

Comment 24

[leger]

Moving this from [nsbeta2+] to [nsbeta2-] since this has now become a meta bug.

Comment 25

[Peter Trudelle]

adding meta keyword

Comment 26

[Dan M]

moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone

Comment 27

[Asa Dotzler [:asa]]

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

Comment 28

[Jesse Ruderman]

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

Comment 29

[Jesse Ruderman]

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

Comment 30

[Jesse Ruderman]

Adding mostfreq keyword.

Comment 31

[timeless]

Adding soup. This bug needs to be relnoted (for whichever children it 
maintains). meta -> [nsbeta3-]. Is this an arch issue?
Removing future because I think it was mishandled.

Per asa I'm marking bug 52590 as blocking this.

Relnote text: Don't leave mozilla unattended in any situation where modal 
dialogs might repeatedly open, doing so can result in a runaway mozilla or 
crashing.

Comment 32

[Doug Turner (:dougt)]

I posted this in the xpcom newsgroup:


 Currently, when you call ProcessPendingEvents on an nsIEventQueue, it
process's itself, then walks up the chain of assessors processing each. 
These seams very wrong to me and I can do not understand how nested
event queues have ever worked.  

What you would hope to have, is a call on ProcessPendingEvents which
either nook's if there are child event queues or calls through to the
youngest child.  Certainly, calling up is the wrong way to go.  

Now, this in itself is not 'that' bad.  The major problem is how native
notifications happen.  When we nest an event, a listener registers the
new event with the gtk select list.  When we post an event, GTK is see
the event (e.g. a write on a pipe) and calls a handler.  The handler
calls ProcessPendingEvents on the registered EventQ.  This eventQ will
call up to this assessor and void any event protection!!!

I have corrected ProcessPendingEvents and fixed up the GTK
nsAppShell.cpp.  This should fix most/all problems that we have been
seeing with out of order events.     

Comment 33

[Peter Trudelle]

resolving as wfm, since most dependent bugs are resolved or low priority. Issues
reported late in bug by Timeless and DougT are already resolved.

Comment 34

[Koike Kazuhiko]

The problem described in bug 52894(marked dup of this) wasn't fixed.

(1) Type invalid URL and hit Enter key. Alert dialog appears.
(2) Click another window.
(3) Try to click the browser window of (1). It cannot be clicked.

Comment 35

[Stephen P. Morse]

The problem described in bug 52894 does not occur for me.  I'm running on a 
win-nt platform.

Comment 36

[Koike Kazuhiko]

I tested with Win32 build 2000100908 on Win98.

Comment 37

[John Morrison]

This bug ended it's life as a Meta bug, and was resolved worksfome, as any
further modality bugs should stand on their own. Re-resolving as worksfome.

If bug 52894 is still an issue, then reopen that bug. However, I have tested
that bug on both win2k and win98 with the 10/10 branch builds, and I cannot
reproduce what is described there.

Comment 38

[John Morrison]

verified.

Comment 39

[Doron Rosenberg (IBM)]

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

Comment 40

[Doron Rosenberg (IBM)]

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