Floating UI Position Incorrect When Modal is Nested Inside Drawer Component about floating-ui HOT 5 OPEN

Hmm, yeah I see that as well. Not sure what would cause it so will need some investigating.

transform: translate(-50%,-50%)

A new "containing block" gets created in this situation, and most positioning bugs that appear now seem to be related to handling this layout situation

Looks like it's related to collision detection when using shift(). When removing that middleware, it's positioned correctly. One possible workaround is to use an empty boundary shift({ boundary: [] }) instead of the default clippingAncestors. Now it will only detect the root viewport collision instead of the incorrectly-calculated clippingAncestors, which may be fine in many situations with top-layer elements...

from floating-ui.

Yeah most likely the same issue, if you add boundary: [] for hide() as well, it should work. This also goes for autoPlacement, and any other visibility-optimizer ones that perform collision detection.

from floating-ui.

Is this not correct?

from floating-ui.

Is this not correct?

It is working fine on a small screen; however, if I go fullscreen on this page (https://vitejsvitejzzg6c-drf5--5173--7dbe22a9.local-credentialless.webcontainer.io/) and open the drawer, then clicking on the input field to open the panel causes the floating panel's position to be incorrect.

from floating-ui.

Hmm, yeah I see that as well. Not sure what would cause it so will need some investigating.

transform: translate(-50%,-50%)

A new "containing block" gets created in this situation, and most positioning bugs that appear now seem to be related to handling this layout situation

Looks like it's related to collision detection when using shift(). When removing that middleware, it's positioned correctly. One possible workaround is to use an empty boundary shift({ boundary: [] }) instead of the default clippingAncestors. Now it will only detect the root viewport collision instead of the incorrectly-calculated clippingAncestors, which may be fine in many situations with top-layer elements...

Thank you for sharing the workaround. There is one more issue I found in our application regarding the issue with the hide middleware, it seems that it returns 'hide', which might be causing the panel to not open consistently. Do you think this could be related to the same issue you mentioned earlier

If I set the display property based on the hide flag, the panel always remains closed.

export function useFloatingUI(trigger: any, panel: any) {
  computePosition(trigger, panel, {
    middleware: middleware,
    strategy: 'fixed',
  }).then(({ x, y, middlewareData }) => {
    const { hide } = middlewareData;
    Object.assign(panel.style, {
      left: `0px`,
      top: `0px`,
      transform: `translate(${x}px, ${y}px)`,
      // display:hide ? 'none': 'block'
    });
  });
}

from floating-ui.