Closed Bug 533592 Opened 10 years ago Closed 10 years ago
Get rid of xpcnativewrappers=no
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.
Assignee: nobody → jorendorff
OS: Linux → All
Hardware: x86 → All
Attachment #447716 - Flags: review?(mrbkap) → review+
Attachment #447717 - Flags: review?(mrbkap) → review+
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
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
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.
Target Milestone: --- → mozilla1.9.3a5
Added a note to the XPCOM changes in Firefox 4 page: https://developer.mozilla.org/en/XPCOM/XPCOM_changes_in_Gecko_2.0#XPCNativeWrapper_changes 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.
You need to log in before you can comment on or make changes to this bug.