Compare Revisions

XPCNativeWrapper

Revision 93094:

Revision 93094 by Varmaa on

Revision 93095:

Revision 93095 by Arno. on

Title:
XPCNativeWrapper
XPCNativeWrapper
Slug:
XPCNativeWrapper
XPCNativeWrapper
Tags:
DOM, Extensions, Add-ons, Security, XPCNativeWrapper
DOM, Extensions, Add-ons, Security, XPCNativeWrapper
Content:

Revision 93094
Revision 93095
n8      <code>XPCNativeWrapper</code> is a way to <a href="en/XPConn8      <code>XPCNativeWrapper</code> is a way to <a href="/en/XPCo
>nect_wrappers">wrap up</a> an object so that it's <a href="en/Saf>nnect_wrappers" title="en/XPConnect_wrappers">wrap up</a> an obje
>ely_accessing_content_DOM_from_chrome">safe to access from privil>ct so that it's <a href="/en/Safely_accessing_content_DOM_from_ch
>eged code</a>. It can be used in all Firefox versions, though the>rome" title="en/Safely_accessing_content_DOM_from_chrome">safe to
> behavior changed somewhat starting with Firefox 1.5 (Gecko 1.8).> access from privileged code</a>. It can be used in all Firefox v
> See <a class="external" href="http://kb.mozillazine.org/XPCNativ>ersions, though the behavior changed somewhat starting with Firef
>eWrapper">the entry for <code>XPCNativeWrapper</code> at the Mozi>ox 1.5 (Gecko 1.8). See <a class="external" href="http://kb.mozil
>llaZine KnowledgeBase</a> for the behavior of <code>XPCNativeWrap>lazine.org/XPCNativeWrapper">the entry for <code>XPCNativeWrapper
>per</code> in Firefox versions prior to 1.5. This document addres></code> at the MozillaZine KnowledgeBase</a> for the behavior of 
>ses <code>XPCNativeWrapper</code> in Firefox 1.5 and later.><code>XPCNativeWrapper</code> in Firefox versions prior to 1.5. T
 >his document addresses <code>XPCNativeWrapper</code> in Firefox 1
 >.5 and later.
n26      The differences in behavior between the three types of <codn26      The differences in behavior between the three types of <cod
>e>XPCNativeWrapper</code> are determined by two characteristics a>e>XPCNativeWrapper</code> are determined by two characteristics a
>n <code>XPCNativeWrapper</code> wrapper can have. An <code>XPCNat>n <code>XPCNativeWrapper</code> wrapper can have. An <code>XPCNat
>iveWrapper</code> can be <a href="#Explicit_vs._Implicit"><i>expl>iveWrapper</code> can be <a href="#Explicit_vs._Implicit"><em>exp
>icit</i></a> (or the opposite, <i>implicit</i>) and can be <a hre>licit</em></a> (or the opposite, <em>implicit</em>) and can be <a
>f="#Deep_vs._Shallow"><i>deep</i></a> (or the opposite, <i>shallo> href="#Deep_vs._Shallow"><em>deep</em></a> (or the opposite, <em
>w</i>). The type of wrapper created is determined by <a href="#Cr>>shallow</em>). The type of wrapper created is determined by <a h
>eating_XPCNativeWrapper_objects">the way it was created</a> as fo>ref="#Creating_XPCNativeWrapper_objects">the way it was created</
>llows:>a> as follows:
n135      By default, <b>all content packages are protected</b>. Thisn135      By default, <strong>all content packages are protected</str
> means that all URIs that start "<tt><a class=" external" href="c>ong>. This means that all URIs that start "<code><a class=" exter
>hrome://" rel="freelink">chrome://</a>&lt;package name&gt;/conten>nal" href="chrome://" rel="freelink">chrome://</a>&lt;package nam
>t/</tt>" (for any package) are protected. Individual packages can>e&gt;/content/</code>" (for any package) are protected. Individua
> <a href="en/Chrome_Registration#xpcnativewrappers">override this>l packages can <a href="/en/Chrome_Registration#xpcnativewrappers
> using a flag</a> in their chrome manifest file.>" title="en/Chrome_Registration#xpcnativewrappers">override this 
 >using a flag</a> in their chrome manifest file.
n164      <li>It is a top-level window (e.g. <code>&lt;xul:window&gt;n164      <li>It is a top-level window (e.g. <code>&lt;xul:window&gt;
></code>, <code>&lt;xul:dialog&gt;</code>, or some URI passed to t></code>, <code>&lt;xul:dialog&gt;</code>, or some URI passed to t
>he <tt>-chrome</tt> command-line flag).>he <code>-chrome</code> command-line flag).
n178      Note that whether a window is trusted does <b>not</b> depenn178      Note that whether a window is trusted does <strong>not</str
>d on the URI loaded in the window. So for example, the following >ong> depend on the URI loaded in the window. So for example, the 
>would create trusted windows when used inside a document whose wi>following would create trusted windows when used inside a documen
>ndow is already trusted:>t whose window is already trusted:
n283      As described above, by default in newer Firefox versions <cn283      As described above, by default in newer Firefox versions <c
>ode>XPCNativeWrapper</code>s are created automatically. <b>You do>ode>XPCNativeWrapper</code>s are created automatically. <strong>Y
>n't need to use the <code>XPCNativeWrapper</code> constructor</b>>ou don't need to use the <code>XPCNativeWrapper</code> constructo
>, unless you intend your code to work in older versions of the br>r</strong>, unless you intend your code to work in older versions
>owser or you disabled <code>XPCNativeWrapper</code>s.> of the browser or you disabled <code>XPCNativeWrapper</code>s.
n333      It is possible to set "expando" properties (properties withn333      It is possible to set "expando" properties (properties with
> names that don't correspond to IDL-defined properties) on <code>> names that don't correspond to IDL-defined properties) on <code>
>XPCNativeWrapper</code> objects. If this is done, then chrome wil>XPCNativeWrapper</code> objects. If this is done, then chrome wil
>l be able to see these expando properties, but content will not b>l be able to see these expando properties, but content will not b
>e able to. <b>There is no safe way to set an expando property fro>e able to. <strong>There is no safe way to set an expando propert
>m chrome and have it be readable from content.</b>>y from chrome and have it be readable from content.</strong>
n351      As the name of this section implies, doing so is <b>unsafe<n351      As the name of this section implies, doing so is <strong>un
>/b>. You shouldn't use <code>wrappedJSObject</code> to bypass XPC>safe</strong>. You shouldn't use <code>wrappedJSObject</code> to 
>NativeWrapper in production code.>bypass XPCNativeWrapper in production code.
352    </p>
353    <p>352    </p>
354      {{ Fx_minversion_inline("3") }} In Firefox 3 <code>wrappedJ
>SObject</code> returns yet another wrapper around the content JS  
>object (XPCSafeJSObjectWrapper), which allows you to safely inspe 
>ct the content object. See <a href="en/XPConnect_wrappers#XPCSafe 
>JSObjectWrapper">XPConnect_wrappers#XPCSafeJSObjectWrapper</a>. 
355    </p>353    <p>
354      {{ Fx_minversion_inline("3") }} In Firefox 3 <code>wrappedJ
 >SObject</code> returns yet another wrapper around the content JS 
 >object (XPCSafeJSObjectWrapper), which allows you to safely inspe
 >ct the content object. See <a href="/en/XPConnect_wrappers#XPCSaf
 >eJSObjectWrapper" title="en/XPConnect_wrappers#XPCSafeJSObjectWra
 >pper">XPConnect_wrappers#XPCSafeJSObjectWrapper</a>.
356    <p>355    </p>
356    <p>
357      See <a href="en/Code_snippets/Interaction_between_privilege357      See <a href="/en/Code_snippets/Interaction_between_privileg
>d_and_non-privileged_pages">Interaction between privileged and no>ed_and_non-privileged_pages" title="en/Code_snippets/Interaction_
>n-privileged pages</a> for the better alternatives.>between_privileged_and_non-privileged_pages">Interaction between 
 >privileged and non-privileged pages</a> for the better alternativ
 >es.
n366      <li>Firefox versions 1.5 through 1.5.0.4 have {{ Bug("33709n366      <li>Firefox versions 1.5 through 1.5.0.4 have {{ Bug("33709
>5") }}, which causes wrappers to not be created for protected scr>5") }}, which causes wrappers to not be created for protected scr
>ipts in some cases. Specifically, if a protected script makes a p>ipts in some cases. Specifically, if a protected script makes a p
>roperty access or function call that returns an untrusted object,>roperty access or function call that returns an untrusted object,
> a wrapper will be created. However, if a function in a protected> a wrapper will be created. However, if a function in a protected
> script is called from C++ and an untrusted object is passed as a> script is called from C++ and an untrusted object is passed as a
>n argument to this function, a wrapper will <i>not</i> be created>n argument to this function, a wrapper will <em>not</em> be creat
>. Functions that expect to be called in this way need to <a href=>ed. Functions that expect to be called in this way need to <a hre
>"#XPCNativeWrapper_constructor_call_with_no_string_arguments">do >f="#XPCNativeWrapper_constructor_call_with_no_string_arguments">d
>their own wrapping</a>. This bug is fixed in Firefox 1.5.0.5 and >o their own wrapping</a>. This bug is fixed in Firefox 1.5.0.5 an
>later.>d later.
nn393      <li>Similarly, acces to items by name does not work on an <
 >code>XPCNativeWrapper for a Plugin, a PluginArray, or a MimeTypeA
 >rray. Instead, you should also use namedItem().<br></code>
394      </li>
tt415    <p>
413    <div class="noinclude"></div>{{ languages( { "es": "es/XPCNat416      {{ languages( { "es": "es/XPCNativeWrapper", "fr": "fr/XPCN
>iveWrapper", "fr": "fr/XPCNativeWrapper", "it": "it/XPCNativeWrap>ativeWrapper", "it": "it/XPCNativeWrapper", "ja": "ja/XPCNativeWr
>per", "ja": "ja/XPCNativeWrapper", "pl": "pl/XPCNativeWrapper" } >apper", "pl": "pl/XPCNativeWrapper" } ) }}
>) }} 
417    </p>

Back to History