Background: We currently have various provisions for "remote XUL",
wherein a hostname is whitelisted to:
1) Allow parsing XUL coming from that hostname (not normally alllowed
for the web).
2) Allow access to XPConnect-wrapped objects, assuming someone hands
out such an object.
3) Run XBL JS in the same global as the webpage.
4) Allow access to a "cut down" Components object, which has
Components.interfaces but not Components.classes, for example.
This machinery is also used for the "dom.allow_XUL_XBL_for_file" preference.
The question is what we want to do with this going forward. From my
point of view, I would like to eliminate item 4 above, to reduce
complexity. I would also like to eliminate item 2 above, because that
would get us closer to having the invariant that XPConnect is only used
from system principals. These two changes are likely to break some
remote XUL consumers.
The question is whether we should just go ahead and disable remote XUL
altogether, modulo its usage in our test suites and maybe
"dom.allow_XUL_XBL_for_file" (for local testing). It seems like that
might be clearer than a dribble of breakage as we remove bits like items
2/4 above, slowly remove various bindings, slowly remove support for
some XUL tags, etc...
Thoughts? My gut feeling is that we should just turn off remote XUL
outside the IsInAutomation() and maybe the "dom.allow_XUL_XBL_for_file"
case.
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
