Closed
Bug 667047
Opened 10 years ago
Closed 10 years ago
ArrayBuffer: __proto__ inconsistent behaviour
Categories
(Core :: JavaScript Engine, defect)
Core
JavaScript Engine
Tracking
()
RESOLVED
FIXED
mozilla8
People
(Reporter: nsm, Assigned: nsm)
References
Details
Attachments
(1 file, 1 obsolete file)
3.94 KB,
patch
|
mrbkap
:
review+
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:5.0) Gecko/20100101 Firefox/5.0 Build Identifier: fixes for bug 665355 cause inconsistent behaviour of __proto__ on ArrayBuffers Other JS objects treat __proto__ as a normal property once it has been set to null (the prototype chain is destroyed). test case: var d = new Date(); d.__proto__ = null d.__proto__ = {a:2} assertEq(d.a, undefined) // PASS var x = new ArrayBuffer(); x.__proto__ = null x.__proto__ = {a:2} assertEq(x.a, undefined) // FAIL Reproducible: Always Expected Results: x.a should be undefined.
Updated•10 years ago
|
Assignee | ||
Comment 1•10 years ago
|
||
Attachment #542195 -
Flags: review?(mrbkap)
Comment 2•10 years ago
|
||
Comment on attachment 542195 [details] [diff] [review] Identical behaviour to native JS objects. Review of attachment 542195 [details] [diff] [review]: ----------------------------------------------------------------- ::: js/src/jstypedarray.cpp @@ +279,5 @@ > > if (JSID_IS_ATOM(id, cx->runtime->atomState.protoAtom)) { > + JSObject *proto = obj->getProto(); > + if (proto) { > + if (!SetProto(cx, obj, vp->toObjectOrNull(), true)) This is close, but it isn't quite sufficient. For example consider: var proto = Object.create(null); var normal = {}; var ab = new ArrayBuffer([]); ab.__proto__ = proto; ab.__proto__ = { a: 42 }; normal.__proto__ = proto; normal.__proto__ = { a: 42 }; is(ab.a, normal.a); So the mere existence of a prototype doesn't mean that you have a __proto__ property. How about always unconditionally calling js_SetProperty on the delegate and then detecting whether or not its proto changes and, if it does, changing the arraybuffer's proto? @@ +292,2 @@ > } > + else { Uber-nit: the else should be on the same line as the closing brace for the if.
Attachment #542195 -
Flags: review?(mrbkap)
Updated•10 years ago
|
Assignee: general → nsm.nikhil
Status: UNCONFIRMED → NEW
Ever confirmed: true
Assignee | ||
Comment 3•10 years ago
|
||
Alternative fix for bug 667047 to deal with cases where the prototype is set to null in the JS sense but not in the C++ sense eg. var x = Object.create(null) x is still null in the JS sense but in C++ the JSObject pointer is not NULL, but a valid JSObject. I hope this explanation is valid.
Attachment #542195 -
Attachment is obsolete: true
Attachment #543031 -
Flags: review?(mrbkap)
Comment 4•10 years ago
|
||
(In reply to comment #3) > eg. > var x = Object.create(null) > > x is still null in the JS sense but in C++ the JSObject pointer is not NULL, > but a valid JSObject. I don't understand what this means. x isn't null; it's an object that you can stick properties on and then look those properties up later. It just happens to have a null prototype.
Updated•10 years ago
|
Attachment #543031 -
Flags: review?(mrbkap) → review+
Assignee | ||
Comment 5•10 years ago
|
||
that's what I meant, that for truthiness purposes x is null, but its not really null
Comment 6•10 years ago
|
||
Backed out while investigating a webgl permaorange on mozilla-inbound.
Comment 7•10 years ago
|
||
http://hg.mozilla.org/mozilla-central/rev/96f52c040d20
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
You need to log in
before you can comment on or make changes to this bug.
Description
•