If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Fix behavior of window.close

VERIFIED DUPLICATE of bug 62168

Status

()

Core
Security
P3
normal
VERIFIED DUPLICATE of bug 62168
18 years ago
10 years ago

People

(Reporter: Hugh Kennedy, Assigned: Mitchell Stoltz (not reading bugmail))

Tracking

Trunk
Future
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

18 years ago
it would be nice if the end-user could control how much access client-side
javascript had to the user's machine:

e.g.

 i'd like to allow updates of window.status and enable rollover menus to work,
 but i would like to be able to say that javascript _cannot_ open new windows,
 and i'd like to set bounds on how much javascripts can allocate resource-wise.

..this would mostly be as a user-side defense against malicious script-writers.

i'm willing to look into doing this myself once javascript is working better in
mozilla, but thought i'd enter this rfe incase someone else has thoughts about
how to do this, if it's even possible, etc.

Comment 1

18 years ago
One for the security guys? Or maybe a DOM0 preference setting?
Assignee: rogerl → norris
Component: Javascript Engine → Security: General
QA Contact: pschwartau → junruh

Comment 2

18 years ago
Already implemented, although we aren't planning to have a UI for the 
preferences anytime soon. 

Look at http://www.mozilla.org/projects/security/components/configPolicy.html in 
particular the use of "window.open".

Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → WORKSFORME

Comment 3

18 years ago
A place pref("security.policy.strict.window.open", "noAccess");  to stop pop-up 
windows is
http://bolohead.mcom.com/ncryptsvr.htm

Comment 4

18 years ago
Reopening. This does not appear to be working.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 5

18 years ago
Reassign to mstoltz.
Assignee: nboyd → mstoltz
Status: REOPENED → NEW

Comment 6

18 years ago
Assigning QA to czhang
QA Contact: junruh → czhang
(Assignee)

Comment 7

18 years ago
Nice feature, but not the sort of thing to be adding at this point in the cycle. 
Marking 'Future.'
Target Milestone: --- → Future
(Assignee)

Comment 8

18 years ago
Accepting bug.
Status: NEW → ASSIGNED
(Assignee)

Comment 9

17 years ago
Need to test configurable security on window.open, etc.
Target Milestone: Future → M18
(Assignee)

Comment 10

17 years ago
Reassigning to jtaylor. John, if you haven't yet, could you please write some 
testcases for configurable policies? Try setting default and site-specific 
policies on key properties such as window.open and make sure they're enforced. If 
everything checks out alright, you can close this bug.
Assignee: mstoltz → jtaylor
Status: ASSIGNED → NEW

Comment 11

17 years ago
Adding URL with testcases. First two (window.open and window.close) work, yet 
second two do not. Mitch, do you think a new bug is needed, or just keep this 
open?
Status: NEW → ASSIGNED

Comment 12

17 years ago
-> mstoltz
Assignee: jtaylor → mstoltz
Status: ASSIGNED → NEW
Keywords: nsbeta3
(Assignee)

Comment 13

17 years ago
Changing summary. apparently setting some properties to noAccess doesn't work. 
Looking into it.
Status: NEW → ASSIGNED
Summary: [RFE] fine grained control of javascript functionality → Some configurable policies not working
(Assignee)

Comment 14

17 years ago
There seems to be a problem with the windowinternal.close policy.

If you do:
w=window.open("http://www.yahoo.com");

Then the security manager won't let you do a
w.close()

because the global variable w is seen as belonging to yahoo.com, and the same
origin check fails. I'm not sure how to deal with this. We could allow
cross-domain access to globals; this is the historic behavior.
(Assignee)

Comment 15

17 years ago
Changing description. window.close needs a special security policy (if 
window.opener != self, put up a confirming dialog before closing window, 
otherwise allow). Probably not crucial for shipping, but I'd like a second 
opinion. What do the DOM folks think about this?
Severity: enhancement → normal
Summary: Some configurable policies not working → Fix behavior of window.close
(Assignee)

Comment 16

17 years ago
Marking Future as this is an annoyance only, not a privacy or security problem.
Target Milestone: M18 → Future

Updated

17 years ago
QA Contact: czhang → junruh

Comment 17

17 years ago
Mass changing QA to ckritzer.
QA Contact: junruh → ckritzer
(Assignee)

Updated

17 years ago
Blocks: 32571
(Assignee)

Comment 18

17 years ago

*** This bug has been marked as a duplicate of 62168 ***
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → DUPLICATE

Comment 19

17 years ago
Verified DUPLICATE on:
MacOS90 2001-02-13-04-Mtrunk
LinRH62 2001-02-13-06-Mtrunk MOZILLA
Win98SE 2001-02-13-06-Mtrunk
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.