43390 - Security check on modality breaks alerts/confirms

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect, P3)

Description

[joki (gone)]

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.

Comment 1

[joki (gone)]

Nominating nsbeta2

Comment 2

[John Morrison]

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

Comment 3

[Jay Patel [:jay]]

Putting on [nsbeta2+] radar for beta2 fix. 

Comment 4

[joki (gone)]

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.

Comment 5

[joki (gone)]

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.

Comment 6

[Mitchell Stoltz (not reading bugmail)]

I'll look at this RSN.

Comment 7

[Mitchell Stoltz (not reading bugmail)]

Pushing off to nsbeta3. Not a beta stopper.

Comment 8

[ekrock's old account (dead)]

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. 

Comment 9

[Mitchell Stoltz (not reading bugmail)]

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

Comment 10

[Doug Turner (:dougt)]

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. 

Comment 11

[Mitchell Stoltz (not reading bugmail)]

Fixing this is going to be a real pain, and the risk is minimal, mainly a 4xp 
issue. Retargeting Future.

Comment 12

[Dan M]

I'm claiming this bug is fixed, though without smartening up the security
manager. See bug 180048, which is basically the same bug.