In order to make the decision "what type of wrapper should I create for this object?" depend only on the scope we're looking at and the object (and its scope), we need to do this.
What is the alternative for add-on authors then?
xpcnativewrappers=no was a temporary measure to allow addons to transition to using .wrappedJSObject in the places where they really needed to examine expando properties. If any haven't done so by now, they should.
Getting rid of this will allow us to get rid of the BYPASS code in XPCNativeWrapper.cpp, which is necessary for compartmentalization. Taking.
Created attachment 447716 [details] [diff] [review]
Part 1, get rid of xpcnativewrappers=foo - v1
Created attachment 447717 [details] [diff] [review]
Part 2, get rid of bypass - v1
Ran these through Try Server along with the patches in bug 568379, and it came back beautifully green. :)
Part 1: http://hg.mozilla.org/tracemonkey/rev/1bc36f4d8ea3
Part 2: http://hg.mozilla.org/tracemonkey/rev/8c42fc73321a
For the reference: http://blog.mozilla.com/mrbkap/2010/02/11/xpcnativewrappersno-going-away/
I mentioned this bug at https://developer.mozilla.org/en/Chrome_Registration#xpcnativewrappers for now. Ideally we'd have a migration guide.
Added a note to the XPCOM changes in Firefox 4 page:
Can anyone explain to me exactly how someone would go about updating their code? I have no clue where to even start here.
I transcribed info from mrbkap's blog post to the XPCOM changes in Gecko 2.0 page, but we could still use a good step-by-step migration guide.
*** Bug 568394 has been marked as a duplicate of this bug. ***
Updated more stuff, calling this done.