Make chrome:histograms more usable |
||||||
Issue descriptionchrome:histograms is essentially a big dumb text file that shows the current histograms data in the local client. It's very hard to use when developing/debugging histograms because: - It's huge and takes a long time to reload. - It requires a reload to see updated stats (sometimes you want to do this repeatedly to ensure various things are being collected). - Reloading resets the page position and so you have to search / scroll again to find the histogram you're looking for. - #TIL it has a filter feature, by typing in (a substring of) the name of the histogram in the path (e.g., chrome://histograms/TaskLatencyMicroseconds). But this is totally non-discoverable and hard to use. - The code is Web 1.0 style (just vomits HTML code into a string, no templating, etc). It's only a developer-facing page but I think we can make it better. For starters, some high bang-for-buck changes I've got working but unlanded: 1. Make the title of each histogram clickable, to navigate to the filter view of only~ish that histogram. Makes reloading the page very fast. 2. Add a little text box at the top to let you type in a filter (mainly to promote discoverability of the filter feature). In the future, we can also do some things like: - Nice visual graphs instead of ASCII. - Dynamic refresh of individual graphs without reloading the whole page. - Dynamic filtering of which graphs are shown, when typing in the box. - Don't show any graphs unless something is typed into the filter box (speed up initial load). - Material design refresh so it looks like chrome:flags.
,
Nov 24 2017
Thanks for looking at this! First, one bit of functionality that I think we should try to preserve is the ability to dump all the histogram data to a file for a bug report. Right now, that can be done by simply selecting all and copying the data to save to a file. In the new UI where you plan not to show things as text, I would suggest adding a simple "Save data..." button that downloads the output as a file. The other thing I'd like to mention is my comment on https://bugs.chromium.org/p/chromium/issues/detail?id=786689#c1 Basically, because this is an internal page that only a handful of developers will be using (vs. a billion Chrome users), I would be concerned of increasing the binary size of this supporting code too much. So while I support the improvements, let's try to make them in a way that keeps size down. (For example, it's not obvious to me that having a full-fledged polymer page is worth the binary size cost - vs. just adding some of the proposed functionality as simple html).
,
Nov 26 2017
#2 Yep, I'm very conscious of binary size. I think adding a few usability improvements will slightly increase the binary, but be worth it for debugging. I agree it's probably not worth going to a full polymer page (I'm not sure --- does it actually cost anything if polymer is already included for other pages?) It doesn't need to be pretty, but I think a few usability improvements as mentioned above would make life easier for people implementing or debugging metrics.
,
Jan 29 2018
mathp@ and fdoray@ were thinking of some similar usability enhancements for their Chrome Mon innovation week project this week. cc'ing them mgiuca@, I assume you're not actively working on this, right? So they could start with your WIP CL maybe?
,
Jan 29 2018
Actually it's Sebastien and I
,
Jan 30 2018
Hi, My apologies for not finishing this off. I might just land my CL since it's pretty much working. I just did a pass over it to fix up the escaping. It depends if the reviewers (I've added asvitkine and jam) are happy to keep appending HTML to the top (and adding a <script> section), or whether they'll want it factored out. I likely don't have the time to do a bigger refactoring. It's out for review now (https://chromium-review.googlesource.com/c/chromium/src/+/788643). In the mean time, mathp and sebsg, maybe you can do additional work on a branch based on my above CL?
,
Jan 30 2018
Hey Matt, we've worked on this Monday and are going in quite a drastic direction: https://chromium-review.googlesource.com/c/chromium/src/+/890627 (not actually displaying graphs yet but you can see the spirit!). I'm not sure that we'll be able to share code but we'll keep your functionality ideas!
,
Jan 30 2018
Ah OK, looks like you're gutting all the code. Looks good. Do you think this will be rolling out soon? If not, I might still try to land my code anyway (and you can just rebase it away). But if you're planning to land this week then I'll just abandon mine.
,
Jan 30 2018
Let us see if we get somewhere with the new code. I think it's looking like we will but I can confirm in a few days.
,
Feb 2 2018
fdegros@ sent me yet a different CL to improve this page: https://chromium-review.googlesource.com/c/chromium/src/+/897385 Given there's three competing changes to improve this, I'd like to better understand the next steps. First, mathp@ - what's the state of your changes? Do they overlap with either of the two CLs and are you still planning to continue pursuing them?
,
Feb 2 2018
This is the current state: https://docs.google.com/presentation/d/1M2U3bIXMd4aPd0YJZ-V4grVIlD8gqfXQnz3ZxDc6Ecc/edit?hl=en#slide=id.g307db23881_0_305 (google internal only, sorry) It overlaps quite a bit because we want to be doing away with the ASCII generating part. We do intend on submitting it and move the generation to the client-side (instead of C++ generating ASCII).
,
Feb 2 2018
OK, sounds good. One use case we should ensure not to regress is being able to export the data when coordinating someone on bug reports. Right now, the use case is basically to ask people to copy-paste the output of that page and email or attach to bug reports. I assume this won't work very well with a full HTML page. So I would suggest to instead add a button to export the data - and maybe keep the existing ascii format for that, since that likely would be easiest than inventing a new format.
,
Feb 5 2018
I wasn't aware that other people were already working on it. Good to see that this page will be improved soon! I agree with all what's said. My reaction to chrome://histograms as it is right now was pretty much 😱. I consider any improvement good to take on board. In that regard, I'll promote my CL (https://chromium-review.googlesource.com/c/chromium/src/+/897385) for a couple of seconds: Pros: Cleans up things a bit Doesn't really change the logic (still ASCII-based histograms) Low risk Ready right now ASCII-based histograms are pretty robust, and can be copied-pasted-mailed. Cons: It's not ambitious (still ASCII-based histograms) It might conflict with other efforts to modernize chrome://histograms So, I'll let you decide whether you want to take it on board or not. Even if it is temporary, and get replaced by an awesome UI a bit later, I would consider it a progress. It might even be complementary. We might still want to have an ASCII-based histogram report capability (for debugging or copy-paste-mail) and an awesome dynamic UI.
,
Feb 5 2018
And yes, I also discovered the filtering feature (eg chrome://histograms/Security) by reading the C++ code...
,
Feb 5 2018
I'd rather we go with a single change, rather than having some intermediate churn. We have some internal tools that parse the output, so any changes to the format would require some changes there, so if we know we're going to change the format again soon, I'd rather not go with the intermediate change. So my suggestion is we wait for mathp's change and have that be the new version. If, for some reason, that doesn't pan out - then we can consider the other ones.
,
Feb 5 2018
I noticed that at least one test (PolicyStatisticsCollectorTest.Startup in browser_tests) parses the output. This is pretty fragile. I don't know if there are any other ones. FYI, I recently added to the DevTools protocol two functions allowing to retrieve histograms. https://chromedevtools.github.io/devtools-protocol/tot/Browser#method-getHistograms https://chromedevtools.github.io/devtools-protocol/tot/Browser#method-getHistogram This might be useful when replacing or upgrading tools parsing chrome://histograms.
,
May 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/18170a49b39546ea32d21dc7d61bc82d61529fd0 commit 18170a49b39546ea32d21dc7d61bc82d61529fd0 Author: Mathieu Perreault <mathp@chromium.org> Date: Thu May 17 12:48:15 2018 [Histograms] Revamp of the chrome://histograms page Now a WebUI message handler. Still keeps the same UI for now, but has potential to be more (see earlier patchsets) Bug: 809820, 788270 Change-Id: I9e2de72540f152ad367098d8255492378bbb28a3 Reviewed-on: https://chromium-review.googlesource.com/890627 Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Julian Pastarmov <pastarmovj@chromium.org> Reviewed-by: Bernhard Bauer <bauerb@chromium.org> Reviewed-by: Alexei Svitkine <asvitkine@chromium.org> Commit-Queue: Mathieu Perreault <mathp@chromium.org> Cr-Commit-Position: refs/heads/master@{#559504} [modify] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/chrome/browser/policy/policy_browsertest.cc [modify] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/content/browser/BUILD.gn [delete] https://crrev.com/c70cdb314e37ae58980dd993433748d9c09e64dc/content/browser/histogram_internals_request_job.cc [delete] https://crrev.com/c70cdb314e37ae58980dd993433748d9c09e64dc/content/browser/histogram_internals_request_job.h [delete] https://crrev.com/c70cdb314e37ae58980dd993433748d9c09e64dc/content/browser/histogram_internals_url_loader.cc [delete] https://crrev.com/c70cdb314e37ae58980dd993433748d9c09e64dc/content/browser/histogram_internals_url_loader.h [add] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/content/browser/histograms_internals_ui.cc [add] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/content/browser/histograms_internals_ui.h [add] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/content/browser/resources/histograms/histograms_internals.html [add] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/content/browser/resources/histograms/histograms_internals.js [modify] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/content/browser/webui/content_web_ui_controller_factory.cc [modify] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/content/browser/webui/url_data_manager_backend.cc [modify] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/content/browser/webui/web_ui_url_loader_factory.cc [modify] https://crrev.com/18170a49b39546ea32d21dc7d61bc82d61529fd0/content/content_resources.grd
,
May 23 2018
,
May 23 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f38ba52d12bfbbff75397033b1a140b4ee3e7c4b commit f38ba52d12bfbbff75397033b1a140b4ee3e7c4b Author: Mathieu Perreault <mathp@chromium.org> Date: Wed May 23 19:30:08 2018 [Histograms page] Create a build target for histograms internals JS As well, address comments from https://chromium-review.googlesource.com/c/chromium/src/+/890627 Bug: 809820, 788270 Change-Id: Idb11e6045ad79993792da08245485c3e64259f85 Reviewed-on: https://chromium-review.googlesource.com/1065576 Reviewed-by: calamity <calamity@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Reviewed-by: Avi Drissman <avi@chromium.org> Reviewed-by: Demetrios Papadopoulos <dpapad@chromium.org> Commit-Queue: Mathieu Perreault <mathp@chromium.org> Cr-Commit-Position: refs/heads/master@{#561202} [modify] https://crrev.com/f38ba52d12bfbbff75397033b1a140b4ee3e7c4b/BUILD.gn [add] https://crrev.com/f38ba52d12bfbbff75397033b1a140b4ee3e7c4b/content/browser/resources/BUILD.gn [add] https://crrev.com/f38ba52d12bfbbff75397033b1a140b4ee3e7c4b/content/browser/resources/histograms/BUILD.gn [add] https://crrev.com/f38ba52d12bfbbff75397033b1a140b4ee3e7c4b/content/browser/resources/histograms/OWNERS [modify] https://crrev.com/f38ba52d12bfbbff75397033b1a140b4ee3e7c4b/content/browser/resources/histograms/histograms_internals.html [modify] https://crrev.com/f38ba52d12bfbbff75397033b1a140b4ee3e7c4b/content/browser/resources/histograms/histograms_internals.js |
||||||
►
Sign in to add a comment |
||||||
Comment 1 by mgiuca@chromium.org
, Nov 24 2017