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)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla1.8.1

People

(Reporter: brendan, Assigned: brendan)

References

Details

(Keywords: fixed1.8.1)

Attachments

(1 file)

This is a standards violation and an optimization hazard. Trivial patch next. /be
Attached patch fixSplinter Review
Attachment #241369 - Flags: review?(igor.bukanov)
Attachment #241369 - Flags: review?(mrbkap)
Attachment #241369 - Flags: approval1.8.1?
Attachment #241369 - Flags: approval1.8.1.1?
Attachment #241369 - Flags: review?(igor.bukanov) → review+
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.
(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
Attachment #241369 - Flags: review?(mrbkap) → review+
Would it be better for compatibility to search prototype chain for the real scope?
(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
Flags: in-testsuite-
Comment on attachment 241369 [details] [diff] [review] fix Approved for RC3.
Attachment #241369 - Flags: approval1.8.1? → approval1.8.1+
Attachment #241369 - Flags: approval1.8.1.1?
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.

Attachment

General

Created:
Updated:
Size: