Closed
Bug 355590
Opened 18 years ago
Closed 18 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•18 years ago
|
||
Attachment #241369 -
Flags: review?(igor.bukanov)
Assignee | ||
Updated•18 years ago
|
Attachment #241369 -
Flags: review?(mrbkap)
Attachment #241369 -
Flags: approval1.8.1?
Attachment #241369 -
Flags: approval1.8.1.1?
Updated•18 years ago
|
Attachment #241369 -
Flags: review?(igor.bukanov) → review+
Comment 2•18 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•18 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•18 years ago
|
Attachment #241369 -
Flags: review?(mrbkap) → review+
Comment 4•18 years ago
|
||
Would it be better for compatibility to search prototype chain for the real scope?
Assignee | ||
Comment 5•18 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: 18 years ago
Resolution: --- → FIXED
Updated•18 years ago
|
Flags: in-testsuite-
Comment 6•18 years ago
|
||
Comment on attachment 241369 [details] [diff] [review]
fix
Approved for RC3.
Attachment #241369 -
Flags: approval1.8.1? → approval1.8.1+
Updated•18 years ago
|
Attachment #241369 -
Flags: approval1.8.1.1?
Assignee | ||
Comment 7•18 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
•