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.
> 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."
> 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
|
