On Tue, Mar 27, 2018 at 03:48:24PM +0000, Dave Townsend wrote:
My understanding is that it has been effectively unsupported for some time
anyway so I think we should just go ahead and disable it altogether at this
point. If we need bits for automated tests then we should work to switch
tests away from those if we can.
This has been my understanding too. When we removed support for
remote XUL by default, and then eventually moved it to a site
whitelist, those were both stepping stones to removing support
entirely. But it's been officially unsupported since the first
step, and there hasn't been any way to enable it since we
removed legacy extension support.
It's also been progressively breaking over time, and I've been
WONTFIXing bugs about remote XUL with prejudice.
If whatever support is left is causing development friction, we
should just remove it.
On Tue, Mar 27, 2018 at 8:36 AM Boris Zbarsky <bzbar...@mit.edu> wrote:
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
