Closed
Bug 355590
Opened 17 years ago
Closed 17 years ago
__parent__ should not expose lexical scope or activation objects
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla1.8.1
People
(Reporter: brendan, Assigned: brendan)
References
Details
(Keywords: fixed1.8.1)
Attachments
(1 file)
1.13 KB,
patch
|
igor
:
review+
mrbkap
:
review+
mtschrep
:
approval1.8.1+
|
Details | Diff | Splinter Review |
This is a standards violation and an optimization hazard. Trivial patch next. /be
Assignee | ||
Comment 1•17 years ago
|
||
Attachment #241369 -
Flags: review?(igor.bukanov)
Assignee | ||
Updated•17 years ago
|
Attachment #241369 -
Flags: review?(mrbkap)
Attachment #241369 -
Flags: approval1.8.1?
Attachment #241369 -
Flags: approval1.8.1.1?
Updated•17 years ago
|
Attachment #241369 -
Flags: review?(igor.bukanov) → review+
Comment 2•17 years ago
|
||
Comment on attachment 241369 [details] [diff] [review] fix >+ /* Censor activations and lexical scopes per ECMA-262. */ But ECMA does not have __parent__! Or to be precise it never exposes the activation objects to scripts.
Assignee | ||
Comment 3•17 years ago
|
||
(In reply to comment #2) > (From update of attachment 241369 [details] [diff] [review] [edit]) > >+ /* Censor activations and lexical scopes per ECMA-262. */ > > But ECMA does not have __parent__! Or to be precise it never exposes the > activation objects to scripts. Yes, that's the point! ;-) /be
Status: NEW → ASSIGNED
Updated•17 years ago
|
Attachment #241369 -
Flags: review?(mrbkap) → review+
Comment 4•17 years ago
|
||
Would it be better for compatibility to search prototype chain for the real scope?
Assignee | ||
Comment 5•17 years ago
|
||
(In reply to comment #4) > Would it be better for compatibility to search prototype chain for the real > scope? __parent__ was always just a reflection of JSSLOT_PARENT. So compatibility is maintained by leaving the code alone, just censoring the lexical scope objects. It turns out that __parent__ is handy for debugging (possibly for the testsuite too) as a way to get to the Call object, but we can provide an alternative method for the suite if we have to. The other, valid uses of __parent__ (e.g. to get to the DOM scope chain link) continue to work. We don't want to let would-be lexical scopes to leak via either __proto__ or __parent__, and so the patch does not depend on the id of the built-in property being accessed. Fixed on trunk: Checking in jsobj.c; /cvsroot/mozilla/js/src/jsobj.c,v <-- jsobj.c new revision: 3.292; previous revision: 3.291 done /be
Status: ASSIGNED → RESOLVED
Closed: 17 years ago
Resolution: --- → FIXED
Updated•17 years ago
|
Flags: in-testsuite-
Comment 6•17 years ago
|
||
Comment on attachment 241369 [details] [diff] [review] fix Approved for RC3.
Attachment #241369 -
Flags: approval1.8.1? → approval1.8.1+
Updated•17 years ago
|
Attachment #241369 -
Flags: approval1.8.1.1?
Assignee | ||
Comment 7•17 years ago
|
||
Fixed on the 1.8 branch: Checking in jsobj.c; /cvsroot/mozilla/js/src/jsobj.c,v <-- jsobj.c new revision: 3.208.2.36; previous revision: 3.208.2.35 done /be
Keywords: fixed1.8.1
You need to log in
before you can comment on or make changes to this bug.
Description
•