On Fri, Aug 7, 2015 at 4:06 PM, J. Ryan Stinnett <
jry...@gmail.com> wrote:
>
> AIUI, XUL pages and any of their resources (in-page JS scripts,
> possibly styles and l10n files too) that expect chrome-scope
> (privileged access to Components and friends) currently use chrome://
> today. At the moment, it encompasses ~200 DevTools files of various
> kinds.
>
Yeah, it's still worth trying to come up with a quick way to fix the
confusion with chrome:// URLs. The "in-page JS scripts" is what my browser
loaders solves, and all of them should be able to be converted to
resource:// URLs and still have privileged access to Components through the
loader. I bet those files make up the majority of our chrome:// URLs, but
it'll be a while before we switch them to require-ed modules.
It's probably not a small effort to move in-page chrome:// JS files to use
my browser loader. Each module is executed in it's own scope, so if the
files depend on being in global scope (which a lot of files seem to do), it
will require structural changes.
But moving a lot of those files would further the effort to reduce
chrome:// confusion, as we would have way less chrome:// URLs in the first
place.
>
> It's definitely lower priority than JS modules loaded via require().
> Still, I think it's a source of confusion when you encounter a
> chrome:// URL somewhere and want to know "where do I find this file to
> modify it?". It sounds like your browser loader might reduce the
> problem a bit more for some file types.
>
>
Yeah, still worth looking into fixing chrome:// URLs. That will probably be
a smaller effort than moving off of it for most files, for now.