[BUG] use-headroom behaves weird on mobile devices

[ChiuMungZitAlexander]

What package has an issue

@mantine/hooks

Describe the bug

use-headroom works well on PCs, but not on mobile devices.

When scrolling down, the pinned area is showing and disappearing again and again as below.

https://github.com/mantinedev/mantine/assets/22234622/e5689cd4-0ec4-4d0a-bab5-29532e0143a3

What version of @mantine/hooks page do you have in package.json?

6.0.17

If possible, please include a link to a codesandbox with the reproduced problem

No response

Do you know how to fix the issue

Maybe

Are you willing to participate in fixing this issue and create a pull request with the fix

Yes

Possible fix

touchmove event handling

[haroldherrera]

Did you fix this issue? I am trying to use it with Mantine 7.2.2 but it's still acting weird

[Alimobasheri]

This issue happens as the mobile browser's address bar hides on scroll. The source code for use-headroom doesn't take this height change into consideration.

@rtivital I might be able to work on this issue and fix it. This might be fixed by taking browser's height into consideration in the hook and the function calls of isFixed and the rest. I haven't tested a fix yet.

[rtivital]

You are welcome to submit a PR with a fix

[Alimobasheri]

I think it's impossible to replicate this issue in storybook. The UI of storybook has absolute positioning and the real scrolling behavior of the demo component happens in the i-frame inside the rendering body of a story. Even opening the storybook server in a mobile browser can't help in replicating this.

Mobile browsers' address bars automatically hide when the html tag is scrollable (for example mantine.dev as shown in the video in issue report). I'm currently unsure of how to replicate and fix the bug, since using storybook is the main convention used in this project. I hope you can help me to find a solution for this.

[rtivital]

Click this button

[Alimobasheri]

oh thanks! sorry, I got so busy digging the docs to remove that toolbar that I didn't see this simple button:))

[Alimobasheri]

It looks like removing lines(50, 52) of this hook fixes the issue:

if (isPinned(scrollPosition, scrollRef.current)) {
  return true;
}

But it only happens when useWindowScroll updates state because of a resize ( I can tell you why this causes the conflict if you want to know more) after browser address bar hides. this resize comes with a delay to scroll events. Maybe we can update the useWindowScroll hook to tell us whether source of latest update is resize or scroll. In case of a resize in which the scrollPosition hasn't actually updated the isPinned value shouldn't change.