FormidableLabs/victory

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

Codesandbox

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

  1. Go to Codesandbox.
  2. Click on 'Open a new tab' Copy the url and paste it Safari.
  3. Hover over one of the upper piller.
  4. 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.

Google chrome:
Skärmavbild 2024-03-18 kl  16 16 36 (2)

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.

Safari:
Skärmavbild 2024-03-18 kl  16 16 44

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?