<div dir="ltr">Hi Boris!<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 27, 2018 at 8:36 AM, Boris Zbarsky <span dir="ltr"><<a href="mailto:bzbarsky@mit.edu" target="_blank">bzbarsky@mit.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Background: We currently have various provisions for "remote XUL", wherein a hostname is whitelisted to:<br>
<br>
1)  Allow parsing XUL coming from that hostname (not normally alllowed for the web).<br>
<br>
2)  Allow access to XPConnect-wrapped objects, assuming someone hands out such an object.<br>
<br>
3)  Run XBL JS in the same global as the webpage.<br>
<br>
4)  Allow access to a "cut down" Components object, which has Components.interfaces but not Components.classes, for example.<br>
<br>
This machinery is also used for the "dom.allow_XUL_XBL_for_file" preference.<br>
<br>
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.<br>
<br>
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...<br>
<br>
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.<br></blockquote><div><br></div>I am not expert in this area, but this sounds like a vestigial feature of the Mozilla XUL application layer that should be removed immediately.  Can you elaborate on:</div><div class="gmail_quote"><br></div><div class="gmail_quote">- some of the details of "likely to break remote XUL consumers"?  Which consumers are these -- internal?  External?<br></div><div class="gmail_quote">- do we have an estimate of how much remote XUL is used in our own test suite?  Is this days/weeks/months of labour to replace?</div><div class="gmail_quote">- do we have any idea of the popularity of `dom.allow_XUL_XBL_for_file`?  Do we expect this usage is all internal?  (I really hope so!)</div><div class="gmail_quote"><br></div><div class="gmail_quote">Sorry to ask for work (before you do the real work),<br></div><div class="gmail_quote">Nick<br></div></div></div></div>