Safari Tooltip Incorrect Size Scaling in VictoryBar with VictoryTooltip
ledei opened this issue · 7 comments
Is there an existing issue for this?
- I have searched the existing issues
Code of Conduct
- I agree to follow this project's Code of Conduct
Victory version
"victory": "^37.0.0"
Code Sandbox link
Bug report
Using the join("\n")
method within the labels
prop on VictoryBar
incorrectly scales the displayed tooltip upon hovering, increasing significantly in size, to a much larger degree than expected. To the best of my findings this only seems to happen in Safari, when utilizing the VictoryBar
component in conjunction with VictoryTooltip
as its labelComponent.
Steps to reproduce
- Go to Codesandbox.
- Click on 'Open a new tab' Copy the url and paste it Safari.
- Hover over one of the upper piller.
- See error.
Expected behavior
The tooltip (VictoryTooltip) should maintain a consistent and appropriate size when hovered, similar to its behavior in other browsers, and should not excessively enlarge regardless of the amount of new lines in the label.
Actual behavior
Upon hover, the size of the tooltip (VictoryTooltip) expands disproportionately, far beyond the expected degree of enlargement. This issue has been noted in Safari, while not manifesting in Google Chrome, the only other browser tested thus far. However, it's important to acknowledge that this behavior may extend to other browsers that have not yet been examined.
Environment
- Device: Desktop
- OS: macOS Version 14.3.1
- Browser: Safari
Thanks for the bug report @ledei, I am able to reproduce this.
One thing to note is that /n
is not valid syntax. To produce muti line labels, simply pass an array.
labels={() => ["this", "is", "a", "multiline", "label"]}
Dev notes: In testing, it looks like our measurement utils are affected by this outstanding bug which causes Safari to return the bounds of the containing <text>
element instead of the target <tspan>
element. Possible solutions could be wrapping every <tspan>
in a <text>
element.
Thank you so much for your quick response @carbonrobot! It's greatly appreciated.
Thanks for the bug report @ledei, I am able to reproduce this.
One thing to note is that
/n
is not valid syntax. To produce muti line labels, simply pass an array.labels={() => ["this", "is", "a", "multiline", "label"]}
It looks like I'm facing a similar issue when I send an array instead of a string with /n. Is there anything that I can do to move forward on this?