https://codesandbox.io/s/strange-hooks-nukkq?file=/src/index.js
Popper should stay on the bottom side of the reference element when scrolling.
Popper goes up as far as the scroll position changes.
What version of Safari are you on? With 13.1 everything looks good to me.
The version is 13.1.1. It's important to use the pinch-to-zoom gesture on the trackpad, not command+plus. Or use a mobile browser.

Oh ok thanks, I missed that step, yes I can reproduce it.
Hey, we're running into this issue too!
Looking at the example, it seems like some logic kicks-in whenever it's pinch zoomed. The logic will manually reposition popper (see attached) on scroll thereafter.
I'm completely new to this project so sorry if I'm stating the obvious here but i hope it helps anyway - ha 馃槣 I'll have poke around today and see if i can find anything else.

After some more digging i've found that the issue is related to this line:
The result of this calculation x -= offsetParent.clientWidth - popperRect.width; changes when we use cmd + and cmd - but if you use pinch to zoom, the calculation remains the same, as if there was no zoom at all.
For example:
x -= offsetParent.clientWidth - popperRect.width; = 366x -= offsetParent.clientWidth - popperRect.width; = 313x -= offsetParent.clientWidth - popperRect.width; = 366Right now i'm thinking that the offsetParent.clientWidth isn't being updated in Safari like we would otherwise expect.
hmmm. appears that this is the culprit: https://stackoverflow.com/questions/6163174/detect-page-zoom-change-with-jquery-in-safari
Safari wont include the zoom in clientWidth & clientHeight but it will update the window.innerWidth / Height...
@danieldelcore I can still reproduce it updating to 2.4.1 & 2.4.2 in the CodeSandbox
Sorry about that, yea can still confirm that this is an issue
I took some time to investigate this issue today, and it looks like like the issue is caused at least in part by a Webkit bug with calculating getBoundingClientRect() when using pinch-to-zoom. Popper.js wraps this function and uses it in a bunch of places to calculate positioning. I assume the same bug causes the inconsistencies with offsetParent that Dan mentioned above.
The bug is tracked in the Webkit issue tracker here, including a simpler popper example as a demonstration: https://bugs.webkit.org/show_bug.cgi?id=207089
I'll look into whether there's an alternate way we can calculate the reference's bounding box and position, and will update in a few hours
Oh right I made that bug report 馃
Most helpful comment
Oh right I made that bug report 馃