Popper-core: Safari + position: fixed + parent with CSS `will-change` = Misplaced popover

Created on 30 Jul 2020  路  4Comments  路  Source: popperjs/popper-core

Phew, this one took me half a day to track down and reproduce. The combination of browser (Safari) and options (strategy: 'fixed') may sound familiar, but this issue is different from #1121.

CodeSandbox demo

https://codesandbox.io/s/popperjs-safari-bug-reproduction-6olmm

Steps to reproduce the problem

  1. Use popper with strategy: 'fixed' within an element that has the CSS rule will-change: transform
  2. Observe that the popover is not attached to its reference anymore

What is the expected behavior?

  • The popover should be properly positioned relative to the viewport, even when some of its parents use CSS will-change
    image

What went wrong?

  • The popover's positioning appears to be calculated relative to the parent element with will-change, however since strategy: 'fixed' needs positioning values relative to the viewport, the popover appears in the wrong place:
    image

Any other comments?

This seems to have been a regression in 2.4.1. The issue doesn't occur in 2.4.0.

# BUG 馃悶 triage

Most helpful comment

@FezVrasta we all know that containing block detection is broken, and it works differently in every browser. Maybe we should make it possible in such special cases to pass over the element according to which the popper should calculate. Maybe even as experimental.

you can also try to use the way the mezr does it. But it can kill the performance.

All 4 comments

It's more Safari problem than Popper.
Safari does not create containing block for elements that have will-change: transform property. On Safari You also need to set transform: translate(0); then it will work.

In older version of popper there was a bug with incorrect detection of containing block, since it was fixed and according to https://developer.mozilla.org/en-US/docs/Web/CSS/Containing_block the problem is with Safari.

It's more Safari problem than Popper.

Fair enough, figuring out the containing block seems to be a tricky problem.

It would be a good idea to add a note about this to the Browser Support section on the website, I'll see if I can make some time to make a PR for this.

Wondering if we could do some feature detection to make it work out of the box?

@FezVrasta we all know that containing block detection is broken, and it works differently in every browser. Maybe we should make it possible in such special cases to pass over the element according to which the popper should calculate. Maybe even as experimental.

you can also try to use the way the mezr does it. But it can kill the performance.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

hekigan picture hekigan  路  6Comments

Johann-S picture Johann-S  路  3Comments

FezVrasta picture FezVrasta  路  5Comments

memboc picture memboc  路  3Comments

skitterm picture skitterm  路  5Comments