Thanks for the report!  Some other folks have expressed similar concerns so it's not just you; I agree it's a bit jarring.

Is the concern the mental disconnect between seeing the aggregate numbers first (e.g. counts for Blink CSS) and then seeing numbers that don't add up to what you saw before after clicking, with no other indication of where the original (higher) numbers came from?

The reason I ask is because I plan on displaying some summary statistics (e.g. breakdowns by priority, state, etc.) at the top of the pages, that currently aren't written up - e.g. what's at the top of triage areas in Chrome Dash currently, see https://chromedash.googleplex.com/triage/area?name=webview for an example.  If the Bugs (Priority) and Bugs (State) cards were present in the Chromium Dash display view, would that be sufficient?

I'm a bit wary of adding the functionality exactly as you described, because then you have different rows in the data table indicating different things (one row is count of bugs JUST with that subcomponent, another row right next to it is count of bugs with ALL subcomponents of the subcomponent).  But as noted, I agree that things could be improved, so just want to discuss what'd work best.

Sorry for the delay in replying. My concern is that I want to know the stats for bugs that have Blink>CSS as a component. 

Since each node in the component hierarchy is valid to mark a bug with, it seems that there should be a way to view this information.

I hear your concern. but I really think we need to display information for each node, whether it's a leaf node or not. Perhaps a different color for a rolled up label (ie one with further sublabels)? Or at least it shouldn't be clickable.

Understood.  FWIW this would require rearchitecting a nontrivial chunk of the pipeline; I'll think about it but I wouldn't expect the change in the near term (though I will try to ensure we have an acceptable solution prior to external launch).

Thanks - please let me or dstockwell@ know if we can help with any feedback
on designs.

The following revision refers to this bug:
  https://chrome-internal.googlesource.com/infra/infra_internal/+/3c22cc1786c0e9a603bc88129127bac8772fda71

commit 3c22cc1786c0e9a603bc88129127bac8772fda71
Author: Alex Mineer <amineer@google.com>
Date: Mon Sep 18 17:24:22 2017

This work is complete; you can view the proposed implementation at https://chromiumdash-staging.googleplex.com/components.  It's basically exactly what you were looking for, with the combination of italicizing the current top level component with a tooltip to explain why it's different (you also can't click on it again to drill down further).

Please check it out and let me know what you think.  I'm going to mark this as fixed, but as an FYI, note that chromiumdash.appspot.com will *not* reflect the fixes immediately; we're re-architecting the whole dashboard, and the fix only lives in the new version, not the old.  Pretty soon we'll swap the production instance (the appspot version) to serve from the new code, and you'll see the fix live at that time.

Please reopen if you have any questions or suggested improvements for what's currently implemented.

Awesome - this looks exactly like what I want. Thanks!

I'm guessing the bug counts in the staging instance are just old, as currently https://chromiumdash-staging.googleplex.com/components/Blink/CSS shows 8 for SLO:Triage under the toplevel Blink>CSS label, but clicking on the '8' directs to a crbug search that returns no bugs.

(reopening this just to confirm the answer about the bug counts in staging)

You are correct - we link to the prod instance of Monorail, but while Chromium Dash is in staging, it gathers data for the backend via the staging instance of Monorail, where data is ~6 months out of date.  Correct counts will appear once we've deployed to prod in a few weeks.