Security check on modality breaks alerts/confirms

RESOLVED FIXED in Future

Status

()

defect
P3
normal
RESOLVED FIXED
19 years ago
17 years ago

People

(Reporter: joki, Assigned: security-bugs)

Tracking

({dom0})

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
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.
(Reporter)

Comment 1

19 years ago
Nominating nsbeta2
Severity: normal → major
Status: NEW → ASSIGNED
Keywords: nsbeta2, regression
OS: Windows NT → All
Hardware: PC → All

Comment 2

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

Comment 3

19 years ago
Putting on [nsbeta2+] radar for beta2 fix. 
Whiteboard: [nsbeta2+]
(Reporter)

Comment 4

19 years ago
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.
(Reporter)

Comment 5

19 years ago
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.
Keywords: nsbeta2, regressionnsbeta3
Whiteboard: [nsbeta2+]
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. 
Keywords: 4xp, correctness
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
Whiteboard: [nsbeta3+]
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. 


Keywords: embed
Fixing this is going to be a real pain, and the risk is minimal, mainly a 4xp 
issue. Retargeting Future.
Severity: major → normal
Keywords: embed, nsbeta3
Whiteboard: [nsbeta3+]
Target Milestone: M19 → Future
Keywords: dom0

Updated

17 years ago
Blocks: 180048

Comment 12

17 years ago
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.