DevTools File Migration and chrome:// URLs

[J. Ryan Stinnett]

As part of moving code to /devtools, I am trying to reduce confusion
by making the paths we use in source to reference files match the path
in the source tree more closely.

For JS modules loaded with require, we have enough control that we can
make this happen. But for chrome:// URLs (pages / scripts / styles in
the tool UIs that have chrome privileges), the way forward is less
clear.

I've created an etherpad[1] with more details and several proposals.
Please review it, add comments, and if you like a proposal +1 it, or
make your own proposal.

[1]: https://etherpad.mozilla.org/devtools-chrome-urls

- Ryan

[Axel Hecht]

From an l10n side, the chrome registry "localizes" by package, so
whenever we have a different set of localizations for something, it'd be
good to have a different chrome package.

Down the road, I'd love to have us have a suite of localization of
devtools than firefox, so getting a separation there is great.

It might also make sense to have that before client vs server. I don't
have a use case in my head, though.

I'd be surprised if we ended up with different localization sets for
different tools. Being more granular than needed won't hurt, though.

Just as context. I think that all proposal should "just work" for the
l10n side of things.

Before etherpad went down, I personally preferred Proposal 6, on no
l10n-related reasons, just personal taste.

Axel

[Jeff Griffiths]

( cc'ing Mossop because you mentioned him in the )

As I noted in the etherpad, I really like option #4 mainly because it
produces urls that are identical to source file paths. My fondness is
mainly that having identical paths makes it much easier for new
contributors to understand how the code is laid out.

Can you fill us in more on why this is risky?

On Wed, Aug 5, 2015 at 10:23 PM, J. Ryan Stinnett <jry...@gmail.com> wrote:
> As part of moving code to /devtools, I am trying to reduce confusion
> by making the paths we use in source to reference files match the path
> in the source tree more closely.
>
> For JS modules loaded with require, we have enough control that we can
> make this happen. But for chrome:// URLs (pages / scripts / styles in
> the tool UIs that have chrome privileges), the way forward is less
> clear.
>
> I've created an etherpad[1] with more details and several proposals.
> Please review it, add comments, and if you like a proposal +1 it, or
> make your own proposal.
>
> [1]: https://etherpad.mozilla.org/devtools-chrome-urls
>
> - Ryan

> _______________________________________________
> dev-developer-tools mailing list
> dev-devel...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-developer-tools

[James Long]

I'm not entirely sure this is related, but just to over-communicate: I've
recently been able to move a lot of chrome:// URLs in the debugger to
resource:// ones because of my newly proposed browser loader. The browser
loader loads everything under a specific resource:// URL inside a window
instance, and it created fresh for each iframe instance. It delegates
requires for everything else up to the normal devtools loader.

Since everything using the browser loader is required relative, it's
required relative to the base resource:// URI which is just specified once.
This means that I can practically move all the debugger JS files to use
moz.build and just be dumb resource:// URIs.

I think Ryan is probably talking more about files which *need* to be chrome
URL, like XUL pages. Are there any other file types that need to be Chrome?
If it's only the XUL pages, and everything else is resource://, maybe it's
not worth fixing those few URLs?

[J. Ryan Stinnett]

On Fri, Aug 7, 2015 at 2:44 PM, James Long <jl...@mozilla.com> wrote:
> I'm not entirely sure this is related, but just to over-communicate: I've
> recently been able to move a lot of chrome:// URLs in the debugger to
> resource:// ones because of my newly proposed browser loader. The browser
> loader loads everything under a specific resource:// URL inside a window
> instance, and it created fresh for each iframe instance. It delegates
> requires for everything else up to the normal devtools loader.
>
> Since everything using the browser loader is required relative, it's
> required relative to the base resource:// URI which is just specified once.
> This means that I can practically move all the debugger JS files to use
> moz.build and just be dumb resource:// URIs.
>
> I think Ryan is probably talking more about files which *need* to be chrome
> URL, like XUL pages. Are there any other file types that need to be Chrome?
> If it's only the XUL pages, and everything else is resource://, maybe it's
> not worth fixing those few URLs?

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.

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.

I do agree that the require() modules are the much more important
case, which is why it's great to have solution for that piece.

- Ryan

[James Long]

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.

[Brian Grinstead]

I don’t often find myself adding / removing / referencing chrome URIs. We don’t add new tools very often, and usually once a tool is in place we don’t usually need to add extra script tags or links to stylesheets. I think if the file name is unique it can be found in the tree from the chrome URI by using a fuzzy search in an editor or dxr. The biggest pain I have with chrome URIs is forgetting the path if I want to load a page or resource in a tab, and I don’t know if any of these proposals would make that easier to remember. Note: I’m willing to accept that this is a papercut I’ve just gotten used to and don’t notice anymore - if we’ve gotten feedback that chrome URI mapping is causing problems for contributors we should fix it.

Interestingly, one benefit to having the chrome URIs *not* matching the file tree is that we can do a big file move like we are planning here without affecting addon-compat. So once we make this change we’d better be happy with the file paths and URI structure we choose :). We should also be aware that making this change will break existing add-ons that use something like chrome://browser/skin/devtools/light-theme.css [0], chrome://browser/skin/devtools/controls.png [1], chrome://browser/content/devtools/theme-switching.js [2], etc.

Out of all the options I like proposal 2 - it maps pretty directly to the file path and I don’t think it’s super critical that there's an *exact* match.

[0]: https://github.com/firebug/devtools-extension-examples/blob/4c3248ea52ae4862b990c9b199e9a65b5160592c/CustomTheme/lib/main.js#L18
[1]: https://github.com/firebug/firebug.next/blob/6b4749590353fcf0176f6c2698a1168b06c7c235/chrome/skin/classic/shared/firebug-theme.css#L257
[2]: https://github.com/victorporof/Restartless-Template/blob/b504c1a1dc2549c1be942e1d6d75a2d9a12fa8b5/chrome/tool.xul#L19

Brian

[J. Ryan Stinnett]

I'm moving forward with proposal 2, as that seems to have the most
agreement, and it's also relatively easy to implement.

- Ryan