Closed Bug 180771 Opened 22 years ago Closed 12 years ago

Controllers and commanddispatchers are scary, same with focusedElement and focusedWindow, maybe something else

Categories

(Core :: XUL, defect, P3)

x86
Windows 2000
defect

Tracking

()

RESOLVED FIXED

People

(Reporter: bsharma, Assigned: caillon)

Details

(Whiteboard: [adt2][sg:investigation])

This bug is reported as the issue in the module review and jrgm asked me to make
a bug out of it.

 - make these accessible from chrome only.
Whiteboard: [sg:investigation]
Shouldn't be hard to fix.
Keywords: nsbeta1
Target Milestone: --- → mozilla1.4beta
Do these need to be scriptable *on* non-chrome windows? If so, we'll need to
check that we're accessed from chrome in the getters for these (by calling
IsCallerChrome() in GlobalWindowImpl), if not, we can move these attributes into
nsIDOMChromeWindow.idl.
navtriage:marking need info.  Mitch, can you comment on this bug for Buffy?

thx.
Whiteboard: [sg:investigation] → [sg:investigation][needinfo]
Jag, what's the security risk here?
I think the focusedWindow and focusedElement attributes are the only ones that
might (need to test) give someone access to chrome from non-chrome. The rest
should be okay, and we probably want to provide them to XUL authors.

You can also access the commandDispatcher from nsIControllers, not sure if we
really need it on there.
adt: nsbeta1+/adt2
Keywords: nsbeta1nsbeta1+
Whiteboard: [sg:investigation][needinfo] → [adt2][sg:investigation]
Chris will try to get this for 1.4final, reassigning.
Assignee: jaggernaut → caillon
Target Milestone: mozilla1.4beta → mozilla1.4final
Target Milestone: mozilla1.4final → ---
Priority: -- → P3
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: shrir → xptoolkit.widgets
per comment 0 these are chrome only for sure now.
Group: core-security
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.