Closed Bug 25684 Opened 25 years ago Closed 24 years ago

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

Categories

(Core :: XUL, defect, P2)

x86
Windows 98
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: bugs, Assigned: danm.moz)

References

Details

(4 keywords, Whiteboard: [nsbeta2-][nsbeta3-] needs correct use of modal dialogs; see dependencies)

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.
reassigning to danm as p2 for m16
Assignee: trudelle → danm
Priority: P3 → P2
Target Milestone: M16
*** Bug 25867 has been marked as a duplicate of this bug. ***
*** Bug 26174 has been marked as a duplicate of this bug. ***
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.
Oops, I spoke to soon.  Just checked on the dialog asking for master password 
and it is not modal.  Bug still exists.
  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.
*** Bug 31647 has been marked as a duplicate of this bug. ***
*** Bug 28706 has been marked as a duplicate of this bug. ***
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?
Status: NEW → ASSIGNED
Depends on: 27048
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.
*** Bug 28155 has been marked as a duplicate of this bug. ***
Mass-moving all M16 non-feature bugs to M17, which we still consider to be 
part of beta2
Target Milestone: M16 → M17
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
In certain scenerios (as presented in some of the dupes of this report), this 
bug can lead to a crash.
Keywords: beta2
Summary: modal windows/dialogs are not 100% modal → [crash] modal windows/dialogs are not 100% modal
Keywords: nsbeta2
Adding crash keyword.
Keywords: beta2crash
Putting on [nsbeta2+] radar.  
Whiteboard: [nsbeta2+]
Blocks: 40158
*** Bug 41670 has been marked as a duplicate of this bug. ***
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.
  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.
No longer depends on: 27048
Whiteboard: [nsbeta2+] → [nsbeta2+] partial fix under review
Whiteboard: [nsbeta2+] partial fix under review → [nsbeta2+] cookie dialog flavor largely fixed
*** Bug 43097 has been marked as a duplicate of this bug. ***
  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.)
Whiteboard: [nsbeta2+] cookie dialog flavor largely fixed → [nsbeta2+] needs correct use of modal dialogs; see dependencies
*** Bug 39439 has been marked as a duplicate of this bug. ***
  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.
Moving this from [nsbeta2+] to [nsbeta2-] since this has now become a meta bug.
Whiteboard: [nsbeta2+] needs correct use of modal dialogs; see dependencies → [nsbeta2-] needs correct use of modal dialogs; see dependencies
adding meta keyword
Keywords: meta
moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone
Target Milestone: M17 → Future
*** Bug 47247 has been marked as a duplicate of this bug. ***
*** Bug 52894 has been marked as a duplicate of this bug. ***
*** Bug 53530 has been marked as a duplicate of this bug. ***
Adding mostfreq keyword.
Keywords: mostfreq
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.
Depends on: 52590
Whiteboard: [nsbeta2-] needs correct use of modal dialogs; see dependencies → [nsbeta2-][nsbeta3-] needs correct use of modal dialogs; see dependencies
Target Milestone: Future → ---
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.     
resolving as wfm, since most dependent bugs are resolved or low priority. Issues
reported late in bug by Timeless and DougT are already resolved.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
The problem described in bug 52894 does not occur for me.  I'm running on a 
win-nt platform.
I tested with Win32 build 2000100908 on Win98.
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.
Status: REOPENED → RESOLVED
Closed: 24 years ago24 years ago
Resolution: --- → WORKSFORME
verified.
Status: RESOLVED → VERIFIED
*** Bug 54567 has been marked as a duplicate of this bug. ***
*** Bug 54567 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.