-
Notifications
You must be signed in to change notification settings - Fork 339
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix scroll lock for iOS devices #207
Conversation
As commented here: willmcpo#200 (comment) Other libraries successfully use this strategy on iOS devices, this could be an opt-in to solve many iOS related issues reported here.
When should one use Is it possible to provide a sensible default value that works for everybody in all cases? |
Hi @jtomaszewski, You use |
Any chances this PR will be merged soon? Without the fix this library is basically not usable on iOS devices. |
I am willing to hide the body's overflow by default on iOS, so long as someone can post a minimal example showing where it's needed. I am unable to reproduce any issues on the iOS simulator with the demo (can anybody else?) |
Hi @diachedelic, I am able to reproduce on iOS (iPhone 11) by zooming in vertical layout and always on horizontal layout. Here is a video: issue-520.mp4 |
What I found is that if you scroll on Safari, then stop (so there's no bottom toolbar), then you'll always be able to still scroll if you start your scroll in that bottom area where the toolbar was: Image.from.iOS.MOV |
Yes, mobile safari has some weird behaviour near the toolbar, see https://benfrain.com/the-ios-safari-menu-bar-is-hostile-to-web-apps-discuss/. Does hiding the overflow prevent this then?
… On 7 Jan 2021, at 6:19 am, Joost van Hoof ***@***.***> wrote:
What I found is that if you scroll on Safari, then stop (so there's no bottom toolbar), then you'll always be able to still scroll if you start your scroll in that bottom area where the toolbar was:
https://user-images.githubusercontent.com/5268113/103810945-63697100-505c-11eb-8bd1-9678d038b799.MOV <https://user-images.githubusercontent.com/5268113/103810945-63697100-505c-11eb-8bd1-9678d038b799.MOV>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#207 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACLZQGA47HADE2AAZSMEO3SYSZVNANCNFSM4UNP3M3Q>.
|
Not sure what you mean by hiding the overflow?
What I’ve done is I’ve added a window.onscroll function forcing the scroll back to the original position on top of this library. Not very elegant but it does the job.
… Op 7 jan. 2021 om 07:38 heeft diachedelic ***@***.***> het volgende geschreven:
Yes, mobile safari has some weird behaviour near the toolbar, see https://benfrain.com/the-ios-safari-menu-bar-is-hostile-to-web-apps-discuss/. Does hiding the overflow prevent this then?
> On 7 Jan 2021, at 6:19 am, Joost van Hoof ***@***.***> wrote:
>
>
> What I found is that if you scroll on Safari, then stop (so there's no bottom toolbar), then you'll always be able to still scroll if you start your scroll in that bottom area where the toolbar was:
>
> https://user-images.githubusercontent.com/5268113/103810945-63697100-505c-11eb-8bd1-9678d038b799.MOV <https://user-images.githubusercontent.com/5268113/103810945-63697100-505c-11eb-8bd1-9678d038b799.MOV>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <#207 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AACLZQGA47HADE2AAZSMEO3SYSZVNANCNFSM4UNP3M3Q>.
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
This pull request is for setting |
@diachedelic In my case, setting |
I've tried this library which adds |
Same issue here with me. I am able to scroll from the bottom part of the screen. The weird thing is this issue happens randomly. Sometimes I'm not able to scroll, and sometimes I am. Does hideBodyOverflow() fix the issue ? |
Hi, @joostvanhoof and @Yuivae, This discussion thread is about a PR to set @joostvanhoof the demo at https://bodyscrolllock.vercel.app/ does not include the changes from this PR. The library you tested (https://github.com/FL3NKEY/scroll-lock) is not comparable, body-scroll-lock uses different strategies to prevent the scroll, so please test this PR instead. Thanks you all for your help. |
Been having problems with this on iOS for a while, seems like overflow:hidden is supported now, so can this just be merged in so the npm is updated? Looks like iOS has been updated and this npm doesn't work as well anymore, if you scroll to the bottom of a modal it locks up and you cannot scroll at all. I was also seeing this quite a lot: I tested with overflow:hidden on body and works fine on iOS, so this pull request seems like a good addition to me. |
Can we modify this PR to set the overflow:hidden on body for IOS by default? @jvitela |
Yes, I will make a change to this PR. |
Any update on this? We're running into this issue and could really use this feature to solve some bugs in mobile Safari. |
Hi @willmcpo and @gregorybolkenstijn Setting After several tries and errors I found setting Please try it and let me know if you are Ok with this solution. |
Hi @willmcpo, we are also interested in this PR, is there is chance this gets merged? Thanks! |
👀 |
Published v4.0.0-beta.0 Thanks for the efforts and the patience 🙏 |
Nice one, when is this planned to be released? |
Hello @willmcpo, I'm using the last beta, it is working fine. The only issue is when I open a modal on a Safari mobile, the body position is resetting to the top, but the position is restored back to where it was after closing the modal. Currently, I'm using document.body.style.top = `-${window.scrollY}px`; before opening a modal to not move the background (body). I would appreciate if there is gonna be a fix for this behavior. |
@jvitela are you able to comment on that? |
Hi @narnat, The current body position is already being saved before locking the scroll and later restored after releasing the scroll, see: cca8cda#diff-643a4a126c8da9aa30956ce7bd9a85d41b9703c0b1ae59bf6c24b496afee10beR113 cca8cda#diff-643a4a126c8da9aa30956ce7bd9a85d41b9703c0b1ae59bf6c24b496afee10beR143 If this is not working in your case or not working as expected, can you please provide a minimum example to reproduce it? And also please specify the device you used for testing. |
@jvitela I have also noticed this bug in the new beta. It is happening on both Safari and Chrome on my iPhone 12 Pro with iOS 14.6. |
Hi @BwamNL can you please provide a minimum example to reproduce it? I both pages from the examples/ folder work fine for me. |
@jvitela I have a demo site where it happens: https://sb.flywheelstaging.com/ (u/p: studiobrabo / studiobrabo ) |
@jvitela I debugged a little bit, and i see the problems comes from not adding 'px'. |
Yes, I was also testing this yesterday. The snap is caused when the content area shrinks due to the bottom-bar AND address-bar appearing. This extra code is used to detect if the content area changed and try to adjust the position: cca8cda#diff-643a4a126c8da9aa30956ce7bd9a85d41b9703c0b1ae59bf6c24b496afee10beR125 The intention was to prevent the controls from being hidden if the content shrunk as it would happen in the basic example I think the delay is actually not necessary, since the timeout + animationFrame would ensure this is executed in a separate render cycle. Furthermore you can reduce the snap by adjusting to half the height difference (assuming the address and bottom bar take the same height amount)
We can also discuss if this last part is actually needed or if we should get rid of it, try removing it let us know how it looks. |
@jvitela I commented out everything for iOS (so no body.position fixed), and in our situation it works great without. The bottombar won't snap in, and we don't have problems with scrolling in the back of the modal. (You can check it here https://sb.flywheelstaging.com/ (u/p: studiobrabo / studiobrabo ) Maybe it should be optional for iOS? |
@jvitela It doesn't seem to work with version 4.0.0.beta.0 Here's a demo using the latest beta: And that's the corresponding Codesandbox: If you downgrade the dependency to 3.1.5 it works like expected. |
@jvitela you are right; with two fingers scrolling, it doesn't work. So we are back with the snapping ;) |
for me this does lock the background but i am also not able to scroll in the modal |
@jvitela will the fix be included in the 4.0 version? |
Hi @BwamNL I am not a maintainer of this library so I can't answer that.
|
body-scroll-lock/src/bodyScrollLock.js Line 122 in 157d235
must be the string ending al least with "px", because browsers dont understand what units you want when passing a number to this style prop |
Hi @dkornilove , @BwamNL, @kilianso and @willmcpo I created a new Pull-request which will hopefully fix the issues reported here: #229 Please check it out and let me know if it works for you. |
@@ -229,7 +272,9 @@ export const enableBodyScroll = (targetElement: any): void => { | |||
} | |||
} | |||
|
|||
if (isBodyOverflowHidden) { | |||
if (isIosDevice) { | |||
restorePositionSetting(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
locks.length
should be check there.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe should return before this if lock.length !== 0
if (isIosDevice) {
targetElement.ontouchstart = null;
targetElement.ontouchmove = null;
if (documentListenerAdded && locks.length === 0) {
document.removeEventListener('touchmove', preventDefault, hasPassiveEvents ? { passive: false } : undefined);
documentListenerAdded = false;
}
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
sorry,I opened the review,just sugggestions.
I spotted this weird behavior: it seems there is a bug when you initiate 'touchmove' scroll by going upwards, it doesn't move. If you start scrolling downwards then revert direction it moves upwards fine. |
@meendoo did you test with the latest from this branch (https://github.com/jvitela/body-scroll-lock/tree/patch-1)? and can we move the conversation here #229 ? If the problem is still reproducible can you please upload a video with an example? |
As commented here: #200 (comment)
Other libraries successfully use this strategy on iOS devices, this could be an opt-in to solve many iOS related issues reported here.