Last Comment Bug 533592 - Get rid of xpcnativewrappers=no
: Get rid of xpcnativewrappers=no
Status: RESOLVED FIXED
fixed-in-tracemonkey
: dev-doc-complete
Product: Core
Classification: Components
Component: DOM (show other bugs)
: Trunk
: All All
: -- normal with 1 vote (vote)
: mozilla1.9.3a5
Assigned To: Jason Orendorff [:jorendorff]
:
Mentors:
: 568394 (view as bug list)
Depends on: 533599 573382
Blocks: blazinglyfastthis 563106
  Show dependency treegraph
 
Reported: 2009-12-08 16:44 PST by Blake Kaplan (:mrbkap)
Modified: 2011-01-11 09:03 PST (History)
13 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Part 1, get rid of xpcnativewrappers=foo - v1 (19.58 KB, patch)
2010-05-27 00:27 PDT, Jason Orendorff [:jorendorff]
mrbkap: review+
Details | Diff | Splinter Review
Part 2, get rid of bypass - v1 (9.96 KB, patch)
2010-05-27 00:47 PDT, Jason Orendorff [:jorendorff]
mrbkap: review+
Details | Diff | Splinter Review

Description Blake Kaplan (:mrbkap) 2009-12-08 16:44:49 PST
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.
Comment 1 Shawn Wilsher :sdwilsh 2009-12-08 19:19:23 PST
What is the alternative for add-on authors then?
Comment 2 Boris Zbarsky [:bz] 2009-12-08 21:40:09 PST
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.
Comment 3 Jason Orendorff [:jorendorff] 2010-05-26 22:21:35 PDT
Getting rid of this will allow us to get rid of the BYPASS code in XPCNativeWrapper.cpp, which is necessary for compartmentalization. Taking.
Comment 4 Jason Orendorff [:jorendorff] 2010-05-27 00:27:40 PDT
Created attachment 447716 [details] [diff] [review]
Part 1, get rid of xpcnativewrappers=foo - v1
Comment 5 Jason Orendorff [:jorendorff] 2010-05-27 00:47:20 PDT
Created attachment 447717 [details] [diff] [review]
Part 2, get rid of bypass - v1
Comment 6 Jason Orendorff [:jorendorff] 2010-05-27 12:27:51 PDT
Ran these through Try Server along with the patches in bug 568379, and it came back beautifully green. :)
Comment 9 Nickolay_Ponomarev 2010-06-10 14:13:50 PDT
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.
Comment 10 Eric Shepherd [:sheppy] 2010-08-24 10:05:16 PDT
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.
Comment 11 Eric Shepherd [:sheppy] 2010-09-01 11:48:03 PDT
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.
Comment 12 Phil Ringnalda (:philor) 2010-12-04 20:21:39 PST
*** Bug 568394 has been marked as a duplicate of this bug. ***
Comment 13 Eric Shepherd [:sheppy] 2011-01-11 09:03:47 PST
Updated more stuff, calling this done.

Note You need to log in before you can comment on or make changes to this bug.