Adding backdrop filter to tooltip crashes the placement.

[chdenat]

Hi,

just for information, I got a strange behavior with SlTooltip.

I declare some SlTooltips , all with hoist attributes and try to change css.
Here's my css code :

sl-tooltip{
        --sl-tooltip-border-radius: var(--lgs-border-radius-xs);
        --sl-tooltip-background-color: var(--lgs-tooltip-bg-color);
        --sl-tooltip-color: var(--lgs-tooltip-color);
        --sl-tooltip-font-size: var(--lgs-font-size-s);
        --sl-tooltip-padding: var(--lgs-gutter-xs);
        --sl-tooltip-arrow-size: 0;

    box-shadow: var(--sl-shadow-medium);
    border-color: var(--lgs-tooltip-border-color);
}

This works nice.

If I add a backdrop filter, placement fails: backdrop-filter: blur(3px);

This is a bug, ok, not really a major one for sure. I've read the Note about placement in the doc, but it is strange that this css impacts the placement.

[KonnorRogers]

I unfortunately can't reproduce. Mind making a codepen?

https://codepen.io/paramagicdev/pen/raBNWqv?editors=1100

As for "css impacting placement", im fairly confident the reason is that backdrop-filter changes the "stacking context" of the element which is part of what Floating UI uses to determine placement of anchored elements.

https://web.dev/articles/backdrop-filter#basics

[chdenat]

I forgot to mention something, and it is important... Part of the code is embedded in a drawer.
Here is the codepen https://codepen.io/chdenat/pen/XJrWzmy

There is the same code inside and outside the drawer.

By default, the tooltip is on the top. If there is not enough space, it's on the bottom. This is the case in the left part of the codepen (ie outside drawer), expected behavior.
But in the drawer, it's not the same.
If there is not enough space after the tooltiped button, the tooltip without backdrop is on the top, as expected, but on the bottom when you use backdrop filter.