Positioning the pointer/arrow so it's not always centered in 3.x

[artikhurana]

I upgraded ember tooltip version 2.x to 3.x and found that tooltip is not centered when I hover on text first time and the snapshot is attached for reference -:

After that when I hover again then it is working fine and the snapshot is attached for reference -:

What I believe is that due to lazy loading, the CSS properties are not getting set properly. However, on the next hover, since the element is already present in DOM, the properties get applied correctly.

Any help would be appreciated.

[Max Fierke]

Hi @artikhurana -- It may depend on the CSS of the parent element(s). Would you be able to share some CSS for those and a snippet of the template surrounding the use of ember-tooltips? Does it exhibit the same behavior when passing popperContainer="body" to the tooltip?

[Dianne Eramo]

@maxfierke I just installed ember-tooltips and I'm running into this issue as well - the tooltip renders too close to the element it's attached to on the first render, causing it to overlap the element. The difference in the css appears to be that the transform:translate3d property on the tooltip is calculated differently on the tooltip's first render than on subsequent renders. I've attached screenshots of the tooltip DOM element on the first and second render for reference.

First render:

Second render:

I tried your suggestion of setting popperContainer="body", but that didn't change it in any way.

Any ideas on what might be causing this?

[Max Fierke]

Hi @eramod! Thanks for sharing the images! Since those values are calculated and populated by either popper.js or tooltip.js, I'll have to dig into those two a bit more to get a sense for what might be happening here.

It could be related to the escapeWithReference modifier, which ember-tooltips activates by default. Mind giving it a try with that setting disabled? The popperOptions section in the README has an example of how to disable this option.

[Robbie Wagner]

I'm experiencing this issue as well. Disabling escapeWithReference does not change the behavior.

[Max Fierke]

Has this just started occurring recently (e.g. after an Ember upgrade?)

[Robbie Wagner]

@maxfierke I am not sure exactly when it started happening. An Ember upgrade or yarn upgrade or something could have triggered it. I do not think it was always a problem, but maybe it was and I just didn't notice.

[Max Fierke]

Hey folks, I looked into this a bit yesterday and it seems like it may have been caused by some change in Ember 3.14 or 3.15 that seems to have been resolved by merging #388 to replace ember-wormhole with ember-maybe-in-element.

ember-wormhole used an afterRender-scheduled task (and an observer for changes) to do its positioning of a rendered element vs. the in-element helper, which I think does it in the same render cycle. It could also be related to the new async observer defaults in Octane, but that probably wouldn't explain the original poster's concern (or if y'all are not using Octane yet)

I'll try to get new version out in the next day or two.

[Robbie Wagner]

@maxfierke I believe I did start seeing the issue only after updating to Octane, so the observer changes sounds like a likely culprit. Thanks for tracking this down!

[Max Fierke]

Released a fix in 3.4.2. Hopefully this also fixes the original issue as well, but if not, let me know and I can re-open this.

[Dianne Eramo]

This resolved the issue for me. Thanks!