On 3/27/18 12:56 PM, Brian Grinstead wrote:
Wouldn't keeping it for file:// require us to maintain the infrastructure, or is there something that makes it worse in the whitelisted domain case?
It's a question of what guarantees we offer for XUL working.
Keeping it for file:// requires keeping some of the infrastructure for
parsing XUL and maybe loading XBL if the pref is flipped.
It does not require us to provide access to Components.interfaces or
allow exposure of XPCOM things in those file:// URLs, as long as we're
OK with "not all XUL" working in the file:// context. Which we are.
Supporting remote XUL in general, on the other hand, involves not
breaking compat with already-deployed stuff which may be relying on the
XPCOM object exposure.
So we could have meaningful code removal and invariant strengthening
even while keeping the file:// case. Certainly until we sort out our
test suites there's no _extra_ win from removing the file:// case in
terms of code removal (though again invariants can maybe be somewhat
stronger if we do remove it).
Also, do we load pages in the content process in both cases?
I believe we do, but I have not verified.
I’m inclined to say we should remove it for the file:// as well
OK. Just to be clear, if we expect layout hackers to debug XUL issues,
the file:// case is really useful for that, because it allows using the
layout debugger. I we promise to not make them do that, we can probably
remove the file:// case.
It’s not nearly as convenient, but test cases can still be created by
registering the xul file as a chrome uri and loading it in a tab.
Can't do that in the layout debugger, yes?
-Boris
_______________________________________________
dev-platform mailing list
dev-platform@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-platform
