Improve scroll locking on iOS #2100
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Instead of using the "simple" hack with the `position: fixed;` we now went back to the `touchmove` implementation. The `position: fixed;` causes some annoying issues. For starters, on iOS you will now get a strange gap (due to safe areas). Some applications also saw "blank" screens based on how the page was implemented. We also saw some issues internally, where clicking changing the scroll position on the main page from within the Dialog. Think about something along the lines of: ```html <a href="#interesting-link-on-the-current-page">Interesting link on the page</a> ``` This doesn't work becauase the page is now fixed, and there is nothing to scroll... Instead, we now use the `touchmove` again. The problem with this last time was that this disabled _all_ touch move events. This is obviously not good. Luckily, we already have a concept of "safe containers". This is what we use for the `outside click` behaviour as well. Basically in a Dialog, your `Dialog.Panel` is the safe container. But also third party DOM elements that are rendered inside that Panel (or as a sibling of the Dialog, but not your main app). We can re-use this knowledge of "safe containers", and only cancel the `touchmove` behaviour if this didn't happen in any of the safe containers.
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR further improves scroll locking on iOS.
Instead of using the "simple" hack with the
position: fixed;implemented in #1830 we now went back to thetouchmoveimplementation we used before.The
position: fixed;causes some annoying issues. For starters, on iOS you will now get a strange gap (due to safe areas). Some applications also saw "blank" screens based on how the page was implemented.We also saw some issues internally, where clicking on a link that changes the scroll position on the "main" page from within the Dialog didn't work properly.
Think about something along the lines of:
This doesn't work becauase the page is now fixed, and there is nothing to scroll...
Instead, we now use the
touchmoveimplmentation again. The problem with this last time was that this disabled all touch move events. This is obviously not good.Luckily, we already have a concept of "safe containers". This is what we use for the
outside clickbehaviour as well. Basically in a Dialog, yourDialog.Panelis the safe container. But also third party DOM elements that are rendered inside that Panel (or as a sibling of the Dialog, but not your main app).We can re-use this knowledge of "safe containers", and only cancel the
touchmovebehaviour if this didn't happen in any of the safe containers.Fixes: #1900