Positioning the pointer/arrow so it's not always centered in 3.x about ember-tooltips HOT 10 CLOSED

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

from ember-tooltips.

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.

from ember-tooltips.

This resolved the issue for me. Thanks!

from ember-tooltips.

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?

from ember-tooltips.

@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?

from ember-tooltips.

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.

from ember-tooltips.

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

from ember-tooltips.

@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.

from ember-tooltips.

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.

from ember-tooltips.

@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!

from ember-tooltips.