I don't believe there's any effort like this.

At the same time, I'n skeptical of this proposal because it likely will result in a non-trivial increase in binary size to the Chrome that's shipped to billion of users to benefit only a dozen of developers. I'm not sure such a trade-off is worth it. (Unless it can be done with a very minimal binary size increase.)

However, another option is to have a separate tool (e.g. webpage) where the page's output can be pasted to provide the rich functionality. Happy to chat about how that could work - e.g. it could be a page on our internal dashboards.

+1 to size concerns. I have expressed the same in previous reviews that add new developer only chrome:// pages, for example see https://chromium-review.googlesource.com/c/chromium/src/+/592314#message-013a763e10067368192a58c0863cb20b83e8d681.

I feel like there should be some way to do this along the lines of making the chrome binary contain just code to produce the data dump and a html-import or similar of the viewer code which would get downloaded?

chrome:// pages have very strict requirements for allowing network access (for good reasons,see for example [1], [2]).

Have you considered an approach similar to chrome.developerPrivate API?
 - An API is exposed from Chrome providing the data.
 - An extension can be authored by a Chromium developer, leveraging the API and uploaded to the Web store. Developers who find it useful can install that extension and use it, without burdening Chrome's binary overall (except for the code implementing the API ofcourse).

[1] https://bugs.chromium.org/p/chromium/issues/detail?id=776896
[2] https://bugs.chromium.org/p/chromium/issues/detail?id=683418

Can't read those bugs, but that sounds like a reasonable approach. It seems like there might be room to add some niceties like making a GN arg to compile the extension into the local chromium build or something.  If there other cases where we have developer chrome:// pages that we'd prefer to use this approach it might be worth streamlining/generalizing it a bit?

> If there other cases where we have developer chrome:// pages that we'd prefer to use this approach it might be worth streamlining/generalizing it a bit?

I think this is a larger topic. While I agree that making the API+extension approach easier would benefit Chromium as a whole, there should be a more fleshed out proposal and pitched to Chromium dev + chrome-eng-review.

Having said that, a while ago I had done some investigation about the types of chrome:// pages that currently ship with Chrome. I did not publish the spreadsheet at the time (maybe I will soon, after I update it, since it is probably slightly outdated). Attaching a dump of dev only URLs that I identified at the time (total 67).

Deleted: dev_chrome_urls.txt 1.5 KB

dev_chrome_urls.txt 1.5 KB View Download

I'd be happy with an extension in the google.com webstore that uses a private API, but that'll require security reviews and whatever process there is for Google-authored extensions.

I'd rather not end up with a solution that involves dumping the metrics into a viewer website, as that defeats the purpose of making the metrics easier to use.

I don't think a more usable page would add much size -- a couple 10 KiBs, but I understand that it adds up and we want to avoid needless feature creep. So a gn arg to enable a component extension or maybe a webui is an interesting idea.

[ mac bug triage ]

Just getting this out of our triage queue, excuse the noise.