Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Safari Tooltip Incorrect Size Scaling in VictoryBar with VictoryTooltip #2835

Open
2 tasks done
ledei opened this issue Mar 19, 2024 · 7 comments
Open
2 tasks done

Safari Tooltip Incorrect Size Scaling in VictoryBar with VictoryTooltip #2835

ledei opened this issue Mar 19, 2024 · 7 comments
Labels
Issue: Accepted The submitted issue has been confirmed by the Victory core team Type: Bug 🐛 Oh no! A bug or unintentional behavior

Comments

@ledei
Copy link

ledei commented Mar 19, 2024

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
@ledei ledei added the Type: Bug 🐛 Oh no! A bug or unintentional behavior label Mar 19, 2024
@carbonrobot
Copy link
Contributor

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"]}

@carbonrobot carbonrobot added the Issue: Accepted The submitted issue has been confirmed by the Victory core team label Mar 19, 2024
@carbonrobot
Copy link
Contributor

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.

@ledei
Copy link
Author

ledei commented Mar 19, 2024

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?

@dlabrecq
Copy link
Contributor

dlabrecq commented May 13, 2024

I'm encountering a similar issue with VictoryVoronoiContainer on Safari.

You can reproduce the issue with the existing voronoiDimension example. As you add more data sets, the tooltip grows exponentially. I'm using 4 VictoryScatter components in the example below.

Screenshot 2024-05-13 at 3 52 43 PM

@jane-airen
Copy link

jane-airen commented Jul 18, 2024

Are there any updates on this? I am also encountering this issue

@eatyourpeas
Copy link
Contributor

I think I might be experiencing this behaviour - I am struggling meaningfully to debug it.
I have a custom VoronoiZoom component:

<VictoryChart
  width={1000}
  height={800}
  style={styles.chartMisc}
  domain={computedDomains}
  containerComponent={
      <VictoryZoomVoronoiContainer
          data-testid="label-container"
          containerRef={ref => { chartRef.current=ref} }
          allowZoom={allowZooming}
          allowPan={allowZooming}
          onZoomDomainChange={handleZoomChange}
          zoomDomain={domains}
          labels={({ datum }) => {
              // This the tool tip text, and accepts a large number of arguments
              // tool tips return contextual information for each datapoint, as well as the centile
              // and SDS lines, as well as bone ages, events and midparental heights
              const tooltipTextList = tooltipText(
                  reference,
                  measurementMethod,
                  datum,
                  midParentalHeightData,
                  clinicianFocus,
                  sex
              )
              if (tooltipTextList){
                  return tooltipTextList.join('\n').replace(/^\s+|\s+$/g, '');
              } 
          }}
          labelComponent={
              <VictoryTooltip
                  data-testid='tooltip'
                  constrainToVisibleArea
                  backgroundPadding={5}
                  pointerLength={5}
                  cornerRadius={0}
                  flyoutStyle={{
                      ...styles.toolTipFlyout,
                  }}
                  style={{...styles.toolTipMain}}
              />
          }
          voronoiBlacklist={['linkLine', 'chronologicalboneagelinkline', 'correctedboneagelinkline', 'areaMPH']}
      />
  }
>

The tooltipText function called in the labels element of the VictoryZoomVoronoiContainer returns an array of strings but if I return the array as @ledei suggests I simply get a long single line tooltip with the strings separated by commas, rather than than a multiline tooltip. I therefore add \n elements at the end of each line and strip the ones at the beginning and the end.

In chrome I get expected behaviour:
image
but in Safari I get:
image
this is an improvement on what I had before when I was returning a long concatenated string with /n interspersed for the line breaks:
image

If you have any workarounds to suggest I would be super grateful.

@eatyourpeas
Copy link
Contributor

Update, just in case it helps others.
By taking advantage of the flyoutHeight prop it is possible to use the lineheight of the text to set the height of the tooltip.

...
labelComponent={
  <VictoryTooltip
      data-testid='tooltip'
      constrainToVisibleArea
      backgroundPadding={5}
      pointerLength={5}
      cornerRadius={0}
      flyoutHeight={(datum) => {
          const numberOfLines = datum.text.length;
          return numberOfLines * 18;    // 18 is the line height
      }}
      flyoutStyle={{
          ...styles.toolTipFlyout,
      }}
      style={{...styles.toolTipMain}}
  />
}
...

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Issue: Accepted The submitted issue has been confirmed by the Victory core team Type: Bug 🐛 Oh no! A bug or unintentional behavior
Projects
None yet
Development

No branches or pull requests

5 participants