JS_NewObject currently looks up the prototype object from the passed-in parent's scope. To do so, it does a property lookup and a get, neither of which are apparent when actually looking at the call. This can cause weird results when the parent is untrusted, making implementing wrappers just that much more difficult. It might be worth it to add a new API, something like JS_NewNativeObject that avoids this step by either using some canonical Object.prototype or using a null prototype and leaving it up to the caller to decide if a prototype is actually necessary.

I would feel safer with such an API and all the places that really want it changed to use it -- sure, we could audit, and perhaps we've patched enough JS_SetP{arent,rototype} calls in -- but those are code bloat and this is still an accident waiting to happen. Putting on someone's radar (mine at least). /be

Easy way to win back Ts and gain on general XPConnected DOM perf. /be

Given comment 2 would like to see if we can get something in for Beta4

Want to address in-browser SunSpider regression (bug 415393) probably caused by bug 414452 with a fix to this bug, so making it block that one. /be

Others should weigh in. I chose a simple but imprecise name, JS_NewNativeObject, and avoided future-proofing. Thought about JS_NewObjectNoDefaultProto but it is just too long. /be

Testing help, including any Ts/Txul testing, is welcome. /be

How about JS_NewHostObject? Native's overloaded in our world, though I suppose when called with a NULL clasp it's not creating a Host object in the ECMA sense.

Comment on attachment 302246 [details] [diff] [review] proposed fix I don't have any strong feelings one way or the other about the name. Want to also fix up the JS_NewObject in XPCCrossOriginWrapper.cpp while you're here? Thanks.

Not "Host" object, that's just misleading in light of ECMA-262's usage. Arguably JS_NewObjectNoDefaultProto is best, but too long. Someone get inspired! New patch with XOW case covered soon. /be

JS_NewOrphanObject? (protoless, not parentless? hmmm) JS_NewUnchainedObject? Unfettered?

It's not orphan or protoless, if you pass a non-null proto it's used just as in the JS_NewObject case. The only difference is the lack of default proto triggered by passing null. /be

This will help Ts and probably Txul. /be

s/Exact/Given/g -- JS_NewObjectWithGivenProto. Good to be done with this, will keep an eye on Ts and Txul. /be

Fix is in: js/src/jsapi.c 3.407 js/src/jsapi.h 3.183 js/src/jsobj.c 3.429 js/src/jsobj.h 3.85 js/src/xpconnect/src/XPCCrossOriginWrapper.cpp 1.34 js/src/xpconnect/src/XPCNativeWrapper.cpp 1.73 js/src/xpconnect/src/XPCSafeJSObjectWrapper.cpp 1.28 /be