[Tooltip] Wrongly created initial tooltip positioning after resizing the window enough which results in scrollbars

[Loktor]

• I have searched the issues of this repository and believe that this is not a duplicate.

Expected Behavior

After resizing my window tooltips should be repositioned correctly to avoid unnecessary scrollbars.

Current Behavior

When i resize a window to a certain point which has a tooltip at the edge then the tooltip is wrongly positioned after the resize which results in unnecessary scrollbars. After moving the mouse over the button which creates the tooltip a few times it gets into the correct position

Steps to Reproduce (for bugs)

https://codesandbox.io/s/m7p9qlpjnp

1. Resize the whole window until unnecessary scrollbars appear
2. Simply hover over the button
3. After moving the mouse away and again over the button the tooltip moves
4. After doing that a few times it moves into the correct position it should have been in initially

Context

It currently affects me when i resize my application (see image below) -> then scrollbars appear due to the tooltip position, which shouldn't be there. After moving over and away from the button serveral times the tooltip is positioned correctly.

Your Environment

Tech	Version
Material-UI	1.0.0-beta.22
Browser	Chrome

[mbrookes]

@Loktor That's a weird one! Thanks for the reproducible example.

[djulen]

Looks like I faced a similar problem. In my case, it appears after switching between portrait and landscape mode.
I have a Tooltip (with placement="top") inside Grid, and have the same issue with extra spacing as described in #7466 If I use Grid without Tooltip workaround with padding (described in this comment) works fine.
Also if I add a Tooltip with a short text everything works correctly, but if my tooltip contains long text, small extra spacing appears again. When I switch between portrait and landscape mode extra spacing grows much bigger. When I click tooltip, position is returned to the previous state (with small extra space). Hope attached gif will make my description more clear.

[Loktor]

@mbrookes Yeah i initial was a bit confused when i found it, thought my code might be at fault, until i found out that the tooltip positioning caused the additional scrollbars^^
@djulen Yeah that looks like it is caused by the same thing

I think that the recalculation after the window resize might be at fault here and cause the tooltip to calculate it's position too early? sadly i didn't have time yet to take a deeper look at what might be causing this^^

[noucles]

Same here, in my case, I have action icons in the last column of a table that is overflowing. These action icons are using the Tooltips component and somehow cause the overflow:hidden to be ignored.

[gregnb]

This is a pretty interesting problem so I started off by first putting a border around the Popper injection point to see what is happening.

This is why it takes a couple of hovers for it to slowly move into the right place. So I then looked for where the resize event is being handled. Tooltip.js line 142:

  handleResize = debounce(() => {
    if (this.popper) {
      this.popper._popper.scheduleUpdate();
    }
  }, 166);

Which then calls react-popper and the method for scheduleUpdate is simply a reference to the scheduleUpdate function inside of Popper.js. Now, there seems to be an issue with that method when it comes to resizing windows that they have not resolved yet for window resize.

floating-ui/floating-ui#251

Not sure much can be done until that is resolved unless anyone sees anything else here?

[mbrookes]

@gregnb Thanks for your investigation! 👍

[gregnb]

@mbrookes No problem

[dmythro]

In the mentioned by @gregnb Popper issue said that v1.14.2 fixes this. So, is dependency upgraded already to re-check this?

[gregnb]

@Z-AX Nice catch looks like they did upgrade it. @mbrookes maybe we can close this one out soon with the upgrade?

[rolandjitsu]

I was playing around and tried to see what causes the scrollbars to appear for some tooltips and discovered that removing the transform property on them (transform: translate3d(375px, 715px, 0px);) works as well.

And it seems that floating-ui/floating-ui#251 does not fix the issue described by @djulen which I'm also experiencing.

[dmythro]

Checked, there is upgrade of the lib in v1.2.2, but still it causes problems with positioning.
Example: after initial render some blocks changed height, but tooltips are still where they where and they are over controls (button etc) so it blocks actual usage and I'd say it is a critical one.

Actually, tooltips are broken with this update almost everywhere in our app: sometimes they are also shown behind the Dialog while actually should be inside the dialog's form. Issues with positioning described above.

[oliviertassinari]

I have updated the reproduction to the latest version: https://codesandbox.io/s/rl5m5nxprq.