Skip to content

Conversation

@alexfauquette
Copy link
Member

@alexfauquette alexfauquette commented Dec 10, 2025

Fix #20187

Changelog

  • 📊 The chart item tooltip can now be controlled

@alexfauquette alexfauquette added type: enhancement It’s an improvement, but we can’t make up our mind whether it's a bug fix or a new feature. scope: charts Changes related to the charts. labels Dec 10, 2025
@alexfauquette alexfauquette changed the title [draft][charts] Controll the item tooltip [WIP][charts] Controll the item tooltip Dec 10, 2025
@mui-bot
Copy link

mui-bot commented Dec 10, 2025

Deploy preview: https://deploy-preview-20617--material-ui-x.netlify.app/

Updated pages:

Bundle size report

Bundle Parsed size Gzip size
@mui/x-data-grid 0B(0.00%) 0B(0.00%)
@mui/x-data-grid-pro 0B(0.00%) 0B(0.00%)
@mui/x-data-grid-premium 0B(0.00%) 0B(0.00%)
@mui/x-charts 🔺+619B(+0.18%) 🔺+149B(+0.14%)
@mui/x-charts-pro 🔺+617B(+0.14%) 🔺+157B(+0.12%)
@mui/x-charts-premium 🔺+619B(+0.14%) 🔺+140B(+0.10%)
@mui/x-date-pickers 0B(0.00%) 0B(0.00%)
@mui/x-date-pickers-pro 0B(0.00%) 0B(0.00%)
@mui/x-tree-view 0B(0.00%) 0B(0.00%)
@mui/x-tree-view-pro 0B(0.00%) 0B(0.00%)

Details of bundle changes

Generated by 🚫 dangerJS against 06453a4

@alexfauquette alexfauquette changed the title [WIP][charts] Controll the item tooltip [charts] Control the item tooltip Dec 11, 2025
@codspeed-hq
Copy link

codspeed-hq bot commented Dec 11, 2025

CodSpeed Performance Report

Merging #20617 will not alter performance

Comparing alexfauquette:controll-tooltip-item (06453a4) with master (139a02a)1

Summary

✅ 13 untouched

Footnotes

  1. No successful run was found on master (262e368) during the generation of this report, so 139a02a was used instead as the comparison base. There might be some changes unrelated to this pull request in this report.

@bernardobelchior
Copy link
Member

The tooltip doesn't seem to anchor to its item on scroll:

Screen.Recording.2025-12-16.at.11.25.00.mov


:::warning
Make sure the tooltip `trigger` is set to `"item"`.
Otherwise you might control the item tooltip and render an axis tooltip
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What do you mean by this? If I set it to axis it doesn't seem to work:

Screen.Recording.2025-12-16.at.11.38.37.mov

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly what I meant: it does not work.

Internally the tooltip item is correctly controlled. But you render an axis tooltip so nothing happend

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's exactly what I meant: it does not work.

I see, but I think this wording is a bit confusing, then:

Otherwise you might control the item tooltip and render an axis tooltip

IMO, we should say something like: "Make sure the tooltip trigger is set to "item", otherwise no tooltip will be shown".

@alexfauquette
Copy link
Member Author

alexfauquette commented Dec 16, 2025

The tooltip doesn't seem to anchor to its item on scroll:

I propose an hybrid approach between a <rect /> used as an anchor and the a fake anchor element

  • When tracking pointer position: event already return screen coordinate. Then I use a fake getBoundingClientRect to avoid mapping screen coordinate to SVG corrdinate
  • When tracking nodes, I add a rect at correct position and use it as an anchor

06453a4

@bernardobelchior If you want I can extract this commit in a dedicated PR. It's just that with controlled tooltip it's much easier to reproduce the issue due to scrolling

Comment on lines +173 to +174
anchorRef.current = document.createElementNS('http://www.w3.org/2000/svg', 'rect');
svgRef.current.appendChild(anchorRef.current);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we create this using a portal? I'm worried this will cause issues because we're never removing this rect.

Also, it seems we're creating this rect even if it isn't needed:

Screen.Recording.2025-12-16.at.17.20.44.mov

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why use a portal?

@bernardobelchior
Copy link
Member

I propose an hybrid approach between a <rect /> used as an anchor and the a fake anchor element

  • When tracking pointer position: event already return screen coordinate. Then I use a fake getBoundingClientRect to avoid mapping screen coordinate to SVG corrdinate
  • When tracking nodes, I add a rect at correct position and use it as an anchor

Yeah, I think that's a good solution 👍

@bernardobelchior If you want I can extract this commit in a dedicated PR. It's just that with controlled tooltip it's much easier to reproduce the issue due to scrolling

Maybe it wouldn't be a bad idea because I'm seeing some weird behavior and maybe it's easier to iterate on a smaller PR:

Not sure why, but this doesn't seem to be properly positioned in mobile:

Screen.Recording.2025-12-16.at.17.18.08.mov

Also, the synchronized demo doesn't work very well in mobile because the tooltip item disappears on touch end. I wonder if we should try to keep showing it after touch end to ensure touch users can see it:

Screen.Recording.2025-12-16.at.17.18.49.mov

@alexfauquette
Copy link
Member Author

Not sure why, but this doesn't seem to be properly positioned in mobile:

That' because we add extra space on mobile to avoid having the tooltip hidden under the user thumb

Also, the synchronized demo doesn't work very well in mobile because the tooltip item disappears on touch end. I wonder if we should try to keep showing it after touch end to ensure touch users can see it:

I don't see how to do that. When user don't touch the chart it should disapear. We could add extra parameter or demos to either add a pending time where the tooltip is still visible, or a tooltip that wait for a click outside to close.

@bernardobelchior
Copy link
Member

That' because we add extra space on mobile to avoid having the tooltip hidden under the user thumb

Makes sense 👍

I don't see how to do that. When user don't touch the chart it should disapear. We could add extra parameter or demos to either add a pending time where the tooltip is still visible, or a tooltip that wait for a click outside to close.

Yeah, I thought we could do something with the demo just so it's visible; but then it would be weird because it wouldn't show the correct behavior

);
}}
/>
<pre>Tooltip Item: {JSON.stringify(barTooltipItem, null, 2)}</pre>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<pre>Tooltip Item: {JSON.stringify(barTooltipItem, null, 2)}</pre>

);
}}
/>
<pre>Tooltip Item: {JSON.stringify(pieTooltipItem, null, 2)}</pre>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
<pre>Tooltip Item: {JSON.stringify(pieTooltipItem, null, 2)}</pre>

@github-actions github-actions bot added the PR: out-of-date The pull request has merge conflicts and can't be merged. label Dec 17, 2025
@github-actions
Copy link

This pull request has conflicts, please resolve those before we can evaluate the pull request.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

PR: out-of-date The pull request has merge conflicts and can't be merged. scope: charts Changes related to the charts. type: enhancement It’s an improvement, but we can’t make up our mind whether it's a bug fix or a new feature.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[charts] Add support for click-triggered and controlled tooltips in charts

4 participants