Highlight matched nodes in the stack chart when searching#5935
Highlight matched nodes in the stack chart when searching#5935fatadel wants to merge 1 commit intofirefox-devtools:mainfrom
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #5935 +/- ##
=======================================
Coverage 85.45% 85.45%
=======================================
Files 321 321
Lines 32068 32090 +22
Branches 8745 8835 +90
=======================================
+ Hits 27403 27423 +20
- Misses 4234 4236 +2
Partials 431 431 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Looks acceptable to me visually. Not super pretty but good enough :) |
|
Hm, I'm surprised that the ancestors are also highlighted. I think it adds more visual noise than value. I think it might be better to highlight only the matching nodes, or to see a prototype of it. For example, we also only highlight the matching nodes in the call tree. @mstange wdyt? For example, looking at chrome's devtools: when you search something, it shows only the matching nodes with their real color:
|
|
Also visualization-wise, I was thinking about dimming the unmatched nodes (graying them out) like chrome does. But I'm not so sure if it's better than the current one yet. |
|
@canova I've initially implemented this feature highlighting only the target nodes but then I've noticed this comment from @julienw and therefore re-implemented to highlight the whole path :) I am open to any solution. I like the one you've shared tbh. |
Yeah it sounds more visually appealing to me too :) |
Oh interesting. I don't think I agree with that comment tbh. Since we do the filtering already, only the roots with matching child will be included in the filtered stack chart. I don't really see the benefit of having these highlighted. Happy to hear counter arguments though. |
I think that highlighting just the child works when the child's node is wide enough to be seen, but when it's super small to the point that it's barely visible or even not visible, then it's difficult to understand what's going on IMO. That's why I was mentioning this possible solution. |
|
Sounds good, let me re-implement with dimming then. |
6d0f011 to
7c6932b
Compare
|
Done ✅ Screen.Recording.2026-04-09.at.13.25.57.mov |
7c6932b to
37fd131
Compare
When a search string is active, reduce the opacity of stack chart nodes whose function name does not match. This makes matched nodes visually stand out while non-matching nodes fade into the background.
37fd131 to
c9c8f24
Compare
|
The video above is slightly invalid because it was recorded with dimming opacity of 0.2 and currently it's set to 0.5 (after discussing with @canova) |
|
In the #5935 (comment) screencast, the dimmed text is definitely not accessible (I'm seeing some light grey text on white background with 1.4:1 contrast ratio) Ideally, for accessibility, any state change shouldn't be conveyed only by a change in colors, so maybe here we should flip things: keep the node as they are now, and make the one that matches the search very visible, e.g. with a 2px outline, or a specific icon ? |
or maybe we remove the background color from the "dimmed" nodes and only have a border on them. They would appear quite differently from the matching ones and it would be less tricky to find the right colors. We could still tweak the dimmed node text color so they feel less important |

Closes #1818.
When a search string is active, draw a BLUE_60 border around stack chart boxes whose function name matches. Ancestor call nodes in the path of a match also get a thinner border to highlight the full call node path.
Before reviewing the code changes, I would like you to have a look visually and tell me if that is what you want to see 🤓
This is the profile from the STR of the original issue with the changes of this PR.