-
Notifications
You must be signed in to change notification settings - Fork 683
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
Improve scroll locking #1449
Improve scroll locking #1449
Conversation
This pull request is automatically deployed with Now. Latest deployment for this branch: https://venia-git-jimbo-minicart-height.magento-research1.now.sh |
|
Did you also check the |
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.
Also check this screenshot out. In chrome, I set the height of the
In iOS I have to add an additional height calculation for the iOS footer to achieve the same effect, note the
|
Going to need to move files to |
d1c4352
to
b5c4fe1
Compare
var(--minicart-footer-padding-bottom) | ||
); | ||
overflow-y: scroll; | ||
height: 30rem; |
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.
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.
Also, why not just use vh
units?
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.
The whole problem here is that mobile Safari doesn't understand that the "viewport" shouldn't include browser chrome. So 100vh
works fine in every other browser, but in Safari you end up with buttons sitting underneath the browser UI at the bottom of the screen.
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.
Ok -- can we maybe increase it a tiny bit? As is unchecking the box to add a distinct address doesn't cause the UI to change or move so it's a little bit of a weird UX. Maybe we should add an scroll/focus to the address form when the button is unchecked?
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.
Haha, I was just demoing this to @soumya-ashok and she had the same feedback. I've added an effect to scroll the new fields into view when added.
This has been addressed.
Yes, I'm making that conscious decision. None of the other forms do that—you're supposed to be able to see some of the mask and the cart items underneath. The payments form already has to handle overflow (read: scroll) because it can exceed the height of the viewport, so we might as well reduce it to an intermediate size and let it overflow. |
@@ -79,6 +81,7 @@ const PaymentsFormItems = props => { | |||
/> | |||
</Field> | |||
</div> | |||
<span ref={anchorRef} /> |
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.
I like this. I just wanted to point out that we are expanding this to be 5 lines of form inputs in #1286. I checked and this code will function fine, even if the form is 6 lines long. Beyond that, however, the "Billing Information" banner hides the top of the form. If you could make this resilient to that, such as if the top field/label were scrolled just under the header banner, then that would be best, however I don't think it's worth holding up the PR since, as I said, it'll work as is (3 lines of form inputs) and will work even up to 6 lines.
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.
Just one comment -- if you are going to make changes for it, LMK and I will re-review, otherwise 👍
@jimbo @sirugh Please check below observations -
|
@dpatil-magento is the second one a problem on |
@sirugh Yes, I do see the second issue on |
bottom: 0; | ||
right: 0; | ||
grid-template-rows: min-content 1fr; | ||
height: calc(100% - var(--minicart-header-height)); |
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.
I'm so happy to get rid of this ⭐️
a891c3e
to
71745da
Compare
@dpatil-magento I've fixed the second issue for now. In general, presentation is not great in the Android scenario because the keyboard reduces the viewport height rather than overlaying it, but the checkout forms have now been adjusted to constrain themselves to the viewport. |
Thanks @jimbo , looks good now. |
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.
👍
Description
When the app is masked, such as when a drawer or other modal is open, we intend to prevent scrolling at the window level. Currently, we apply styles to the
<Main>
element to achieve this, but it doesn't work properly in mobile Safari. This PR would shift scroll locking to thehtml
andbody
elements as necessary for mobile Safari.This also resolves a number of visual quirks and inconsistencies in the cart/checkout flow.
100vh
)Related Issue
Closes #1071.
Verification Steps