Closed
Bug 25684
Opened 25 years ago
Closed 24 years ago
[crash] modal windows/dialogs are not 100% modal
Categories
(Core :: XUL, defect, P2)
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.
Comment 1•25 years ago
|
||
reassigning to danm as p2 for m16
Assignee: trudelle → danm
Priority: P3 → P2
Target Milestone: M16
Comment 4•25 years ago
|
||
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•25 years ago
|
||
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.
Comment 9•24 years ago
|
||
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?
Assignee | ||
Comment 10•24 years ago
|
||
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•24 years ago
|
||
*** Bug 28155 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
Mass-moving all M16 non-feature bugs to M17, which we still consider to be part of beta2
Target Milestone: M16 → M17
Comment 13•24 years ago
|
||
spam, open xptoolkit qa contact moving over to jrgm
QA Contact: paulmac → jrgm
Comment 14•24 years ago
|
||
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
Comment 17•24 years ago
|
||
*** Bug 41670 has been marked as a duplicate of this bug. ***
Comment 18•24 years ago
|
||
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.
Assignee | ||
Comment 19•24 years ago
|
||
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+] partial fix under review → [nsbeta2+] cookie dialog flavor largely fixed
Assignee | ||
Comment 20•24 years ago
|
||
*** Bug 43097 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 21•24 years ago
|
||
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.)
Assignee | ||
Comment 22•24 years ago
|
||
*** Bug 39439 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 23•24 years ago
|
||
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•24 years ago
|
||
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
Assignee | ||
Comment 26•24 years ago
|
||
moving en masse all bugs that didn't get nsbeta3 nomination to "future" milestone
Target Milestone: M17 → Future
Comment 27•24 years ago
|
||
*** Bug 47247 has been marked as a duplicate of this bug. ***
Comment 28•24 years ago
|
||
*** Bug 52894 has been marked as a duplicate of this bug. ***
Comment 29•24 years ago
|
||
*** Bug 53530 has been marked as a duplicate of this bug. ***
Comment 31•24 years ago
|
||
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•24 years ago
|
||
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•24 years ago
|
||
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
Comment 34•24 years ago
|
||
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 → ---
Comment 35•24 years ago
|
||
The problem described in bug 52894 does not occur for me. I'm running on a win-nt platform.
Comment 36•24 years ago
|
||
I tested with Win32 build 2000100908 on Win98.
Comment 37•24 years ago
|
||
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 ago → 24 years ago
Resolution: --- → WORKSFORME
Comment 39•24 years ago
|
||
*** Bug 54567 has been marked as a duplicate of this bug. ***
Comment 40•24 years ago
|
||
*** 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.
Description
•