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.

Nominating nsbeta2

*** 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.

I'll look at this RSN.

Pushing off to nsbeta3. Not a beta stopper.

Strongly recc. nsbeta3+; please speak to ekrock directly if considering minusing. Extremely bad things (total loss of consistency between state of executing JS that's waiting for result of alert, vs. the state of windows around it) could happen if, while an alert/confirm is open, the user is able to manipulate the contents/buttons of the window that triggered the alert, close it or other windows, etc. correctness and 4xp. The integrity of our JavaScript alert system is at stake here.

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).

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.