Due to a change in the security permissions on window opening script based alerts and confirms are no longer modal. They need to be changed back. Vidur, mstoltz, and I have discussed how to fix this and Vidur is working on code. It should be ready soon.
*** Bug 43442 has been marked as a duplicate of this bug. ***
Putting on [nsbeta2+] radar for beta2 fix.
This is temporary patched by removing the security check on modality. The security side of the real fix is starting to look hairy so we're waiting for the return of mstoltz to continue the fix.
mstoltz is thinking about ways to fix this in the security manager. Assigning to him as discussed since the modifications to the security manager are 99% of what's left in this bug. That and uncommenting out the bypass of the modal window security check.
Assignee: joki → mstoltz
Status: ASSIGNED → NEW
I'll look at this RSN.
Status: NEW → ASSIGNED
Target Milestone: --- → M17
Pushing off to nsbeta3. Not a beta stopper.
Changing description. Alerts and confirms are still modal. The problem is that when we activate the security check on creating a modal window from script, alerts and confirms break, as they appear to have been generated by web script. I need to bypass the security check in the case of alerts and confirms, then uncomment the security check as it applies to everything else. I would argue this is still beta3, as untrusted web scripts should not be able to create modal windows (4.x has this restriction).
Summary: script alerts/confirms are not modal → Security check on modality breaks alerts/confirms
Target Milestone: M17 → M19
Because of the use of nsCommonDialogs, or the use of the nsIPrompt service, this component can not be used for embedding. Adding the embedding keyword. How To Bring Up A Modal Dialog: You need to know what window you want to have modality against. This will be a nsIDOMWindow. Using a magic "hidden" window breaks modality and embedding application may not have this hack. One you have the parent DOMWindow, you simply: nsCOMPtr<nsIPrompt> prompter; aDOMWinow->GetPrompt(getter_AddRefs(prompter)); if (prompter) prompter-> Any other way that you try to bring up a dialog may not work in an embedding application. To reiterate, do not use the nsICommonDialogs interface -or- a nsIPrompt service if you want your component in a non-seamonkey app. I don't have a DOMWindow?! If you don't have a DOMWindow, you need to get one. Just about every place I saw that used the hidden window, could have used the real parent window with some work. There really is no place in the code where we should be displaying a modal dialog without knowing what parent window we are modal against. If you find a case where you don't have a top level window, lets talk.
Fixing this is going to be a real pain, and the risk is minimal, mainly a 4xp issue. Retargeting Future.
I'm claiming this bug is fixed, though without smartening up the security manager. See bug 180048, which is basically the same bug.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.