Can't access my XBL element because of XPCNativeWrapper

[Jaywalker]

Hey,

I am displaying my XBL elements in the browser using my own protocol,
which has chrome privileges.

Now, when I try to access these elements from the outside (f.ex. from
the firefox main-window), they are wrapped inside a XPCNativeWrapper
and I can't access their methods, except using wrappedJSObject.

How can I expose my methods, so that the wrapper knows about them?
I already tried implementing an IDL interface in my XBL element, but
this doesn't seem to do the trick.

Why does Firefox wrap elements from privileged content into
XPCNativeWrappers anyway?

I am thankful for every hint!

Thanks a lot!

[Boris Zbarsky]

Jaywalker wrote:
> Now, when I try to access these elements from the outside (f.ex. from
> the firefox main-window), they are wrapped inside a XPCNativeWrapper
> and I can't access their methods, except using wrappedJSObject.
>
> How can I expose my methods, so that the wrapper knows about them?

You can't.

> Why does Firefox wrap elements from privileged content into
> XPCNativeWrappers anyway?

What matters isn't the privileges of the content, but the type of window
it's being shown in. You're showing your content in a non-chrome
window, so it gets treated as non-chrome. The right thing to do is to
not put privileged content in non-chrome windows.

-Boris

[Jaywalker]

Thanks for your answer!

> What matters isn't the privileges of the content, but the type of window
> it's being shown in.  You're showing your content in a non-chrome
> window, so it gets treated as non-chrome.  The right thing to do is to
> not put privileged content in non-chrome windows.

in the context of mozilla, "chrome" is an ambiguous word. is a "non-
chrome"-window any window that is displayed as a content, f. ex. a
window loaded by a browser element?

what is the reason for even wrapping objects from privileged sources
into XPCNativeWrappers? In the end, these wrappers are for securing
unprivileged code.

As FF is more and more developing into an application platform than
just a browser, it seems like a drawback for extension-developers that
use the browser tabs for showing their extension content (f. ex. via
chrome URL's; see FireFTP, Firefly, etc). I guess there are situations
where those developers might want to access the content from the
outside (or an extending extension might want to), without using
"hacks" like wrappedJSObject.

Another thing. MDC says:

"The only properties and methods accessible through an
XPCNativeWrapper are those that are defined in IDL or defined by DOM
Level 0."

Why isn't this true for XBL bindings that implement IDL interfaces? I
tried. it didn't work. I don't quite understand why the quote from MDC
is true for html elements (you can access the checked-property of
input-elements), but not for xul/xbl elements. from a non-technical
point of view it doesn't make sense, that you can access unprivileged
html-code, but not privileged xul-code using XPCNativeWrappers. why
are they treated differently?

*hui* a lot of questions. sorry for that.

Thanks a lot for the help.

Cheers.

[Boris Zbarsky]

Jaywalker wrote:
>> What matters isn't the privileges of the content, but the type of window
>> it's being shown in. You're showing your content in a non-chrome
>> window, so it gets treated as non-chrome. The right thing to do is to
>> not put privileged content in non-chrome windows.
>
> in the context of mozilla, "chrome" is an ambiguous word.

Yep.

> is a "non-chrome"-window any window that is displayed as a content, f. ex. a

> window loaded by a browser element?

In this context, it is any window that is either the window for an
<iframe type="content"> or <iframe type="content-something"> or a
<browser> with a type attribute like that or any window that has such a
window on its ancestor chain.

Basically, any window corresponding to a typeContent docshell.

> what is the reason for even wrapping objects from privileged sources
> into XPCNativeWrappers?

At the point at which they need to be wrapped, their source is not
really known. But even more....

> In the end, these wrappers are for securing unprivileged code.

Yes, and you're putting the objects in a place where unprivileged
objects (e.g. the Window object!) are reachable from them. So to
protect privileged code from access to these unprivileged objects,
everything involved needs to be wrapped.

> As FF is more and more developing into an application platform than
> just a browser, it seems like a drawback for extension-developers that
> use the browser tabs for showing their extension content (f. ex. via
> chrome URL's; see FireFTP, Firefly, etc).

You need to either not use browser tabs, or convince the tabbrowser
maintainers to add API to create tabs that are not type="content". I
recommend the latter (as I have for years).

> Another thing. MDC says:
>
> "The only properties and methods accessible through an
> XPCNativeWrapper are those that are defined in IDL or defined by DOM
> Level 0."

That's correct.

> Why isn't this true for XBL bindings that implement IDL interfaces?

It is if you were accessing the binding via an XPCNativeWrapper around
an XPCWrappedNative for that interface (which for the XBL-implements
case would be an XPCWrappedNative wrapped around an XPCWrappedJS wrapped
around the JS object which corresponds to the XPCWrappedNative wrapped
around the actual element C++ object).

Put another way, if your node implements nsIFoo via XBL, and you pass
the node to a method that takes nsIFoo and the callee is C++ and the
callee passes the C++ object it gets back out to JS, and the JS code on
the other end get an XPCNativeWrapper around the thing it got, then
nsIFoo on that XPCNativeWrapper will work.

But in your example, you are not doing that: you're just grabbing the JS
object directly and reading properties off of it. It's not going
through XPConnect for the property gets; it's just going through direct
JSAPI calls, so XPCNativeWrapper never even finds out that those
properties you're trying to get are supposed to be an implementation of
an interface.

Or put yet another way, XBL's implements="" thing doesn't really play
that nice with other parts of the system.

It's _possible_ that you might get the effect you want if you QI the
node to the interface you want and use that QI result instead of just
grabbing properties off of the node. That's technically the right thing
to be doing anyway, and should give you a call chain as in the first
paragraph above. I think. Worth trying at least.

> I don't quite understand why the quote from MDC
> is true for html elements (you can access the checked-property of
> input-elements), but not for xul/xbl elements.

Because the codepaths are very different; see above.

> from a non-technical point of view it doesn't make sense, that you can access unprivileged
> html-code

You can't access the unprivileged parts. That's the whole point of
XPCNativeWrapper.

> but not privileged xul-code using XPCNativeWrappers. why
> are they treated differently?

Because they're implemented totally differently and you're using them
differently? ;)

> *hui* a lot of questions. sorry for that.

Not a problem. Hope the above helps!

-Boris

[Jaywalker]

Thanks, this was really really informative.

Guess I'll try out the QI-ing. and otherwise I do as you said: bug the
tabbrowser-team. bugging people is something i'm good in anyway ;)

Thanks a lot!

Cheers.