Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Ending support for xpcnativewrappers=no

5 views
Skip to first unread message

Blake Kaplan

unread,
Dec 21, 2009, 5:37:13 PM12/21/09
to
When we introduced XPCNativeWrappers, we decided that there needed to be a
transitional period to allow old extensions to update to the new world of
automatic wrappers. In particular, because the new behavior was default-safe
(i.e. no random properties from content), there was a large potential to break
existing code. To this end, we introduced the ability to put
xpcnativewrappers=no in a chrome.manifest. This flag, associated with the
chrome URL under it allowed an extension to opt-out of wrappers. Now, 4 years
later, it's time to put this flag to rest.

Extensions can still get access to the underlying object (modulo safe
wrappers) by using .wrappedJSObject (or the newly-introduced
XPCNativeWrapper.unwrap). In fact, from a security standpoint, it's better to
use .wrappedJSObject anyway, as it more clearly marks code that deals directly
with content properties (e.g. consider document.cookie ===
document.wrappedJSObject.cookie, where the first gives chrome code access to
the document's cookie data, and the second gives chrome code access to a
content-defined bit of data that may or may not be the same thing).

The motivation for doing this change now, as opposed to some time in the
future, is that I'd like to decouple the decision of what wrapper to create
from the filename of the code that uses it. This means that what sort of
wrappers to create becomes a function of the scopes involved only, which are
easier to find than the filename that we're wrapping for.
--
Blake Kaplan

Sheppy

unread,
Dec 21, 2009, 6:01:00 PM12/21/09
to

On what branch, and for what Gecko version, is this intended to take
effect? I need to make sure this gets documented. Is there a bug
number?

Sheppy

Blake Kaplan

unread,
Jan 5, 2010, 6:24:08 PM1/5/10
to
Sheppy <the.s...@gmail.com> wrote:
> On what branch, and for what Gecko version, is this intended to take
> effect? I need to make sure this gets documented. Is there a bug
> number?

Given that this has the extremely large potential to break extensions, this
probably wants to land on trunk ASAP and hit the first release off of trunk
(so possibly not 3.7 if that's based on the 1.9.2 branch). This is
<https://bugzilla.mozilla.org/show_bug.cgi?id=533592>.
--
Blake Kaplan

0 new messages