Skip to content
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

Merged
merged 12 commits into from
Jul 25, 2019
Merged

Improve scroll locking #1449

merged 12 commits into from
Jul 25, 2019

Conversation

jimbo
Copy link
Contributor

@jimbo jimbo commented Jul 18, 2019

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 the html and body elements as necessary for mobile Safari.

This also resolves a number of visual quirks and inconsistencies in the cart/checkout flow.

  • Lock window scrolling and overscrolling when mask is active
  • Fit minicart height to viewport in mobile Safari (replace 100vh)
  • Adjust padding in cart footers (decrease)
  • Adjust payments form height (decrease)
  • Adjust braintree form styles (slightly)
  • Adjust checkout subform header padding (increase)
  • Adjust padding in cart item editor (increase)
  • Fit cart item editor to viewport in mobile Safari (fix auto sizing)

Related Issue

Closes #1071.

Verification Steps

  1. Open the mobile simulator in Xcode.
  2. Go to the deployment of this branch and open the cart.
  3. Verify that the window can't be scrolled (or overscrolled) at all.
  4. Verify that the cart is not obscured by Safari's chrome.

@vercel
Copy link

vercel bot commented Jul 18, 2019

This pull request is automatically deployed with Now.
To access deployments, click Details below or on the icon next to each push.

Latest deployment for this branch: https://venia-git-jimbo-minicart-height.magento-research1.now.sh

@PWAStudioBot
Copy link
Contributor

PWAStudioBot commented Jul 18, 2019

Messages
📖 We are currently working on automating the PR metadata checks. Until that time, you may see failures related to labels/description/linked issues/etc even if you have fixed the problem. Failures will persist until the next push (assuming they are fixed).

Generated by 🚫 dangerJS against 605a44c

@sirugh
Copy link
Contributor

sirugh commented Jul 18, 2019

Did you also check the paymentsForm which relies on the cart height but also some calculations based on footers/etc?

@jimbo jimbo added the version: Minor This changeset includes functionality added in a backwards compatible manner. label Jul 18, 2019
@sirugh sirugh self-assigned this Jul 18, 2019
Copy link
Contributor

@sirugh sirugh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure how this fixes the cart height issue. Did you forget to add a commit?

Image from Gyazo

@sirugh
Copy link
Contributor

sirugh commented Jul 18, 2019

Also check this screenshot out. In chrome, I set the height of the paymentsForm body to:

    height: calc(
        100vh - var(--flow-footer-height) -
            var(--minicart-footer-padding-bottom)
    );

In iOS I have to add an additional height calculation for the iOS footer to achieve the same effect, note the - 7rem:

    height: calc(
        100vh - 7rem - var(--flow-footer-height) -
            var(--minicart-footer-padding-bottom)
    );

Image from Gyazo

@sirugh
Copy link
Contributor

sirugh commented Jul 19, 2019

Going to need to move files to lib.

var(--minicart-footer-padding-bottom)
);
overflow-y: scroll;
height: 30rem;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are you making a conscious decision to not have the billing form span the height of the viewport? If so, I'm fine with this change, but we are definitely changing the way the payment form looks now.

Image from Gyazo

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

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?

Copy link
Contributor Author

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.

@jimbo
Copy link
Contributor Author

jimbo commented Jul 19, 2019

Did you also check the paymentsForm which relies on the cart height but also some calculations based on footers/etc?

This has been addressed.

Are you making a conscious decision to not have the billing form span the height of the viewport? If so, I'm fine with this change, but we are definitely changing the way the payment form looks now.

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} />
Copy link
Contributor

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.

Copy link
Contributor

@sirugh sirugh left a 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 👍

@vercel vercel bot temporarily deployed to staging July 22, 2019 17:08 Inactive
sirugh
sirugh previously approved these changes Jul 22, 2019
@dpatil-magento
Copy link
Contributor

@jimbo @sirugh Please check below observations -

  1. Desktop chrome browser > Home page, search results, category page shifts left on accessing Left/Right drawer.

image.png

  1. On Android - When user access shipping form and tap on Name field - Form shifts up and user cant see whats being typed. (Tried on actual device and also on browser stack virtual device. )

image.png

@sirugh
Copy link
Contributor

sirugh commented Jul 23, 2019

@dpatil-magento is the second one a problem on develop?

@dpatil-magento
Copy link
Contributor

@sirugh Yes, I do see the second issue on develop too but thought that needs to be fixed as part of this ticket as its related to scrolling/focus ?

@vercel vercel bot temporarily deployed to staging July 23, 2019 19:30 Inactive
bottom: 0;
right: 0;
grid-template-rows: min-content 1fr;
height: calc(100% - var(--minicart-header-height));
Copy link
Contributor

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 ⭐️

@jimbo
Copy link
Contributor Author

jimbo commented Jul 24, 2019

@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.

@dpatil-magento
Copy link
Contributor

Thanks @jimbo , looks good now.
QA Pass.

Copy link
Contributor

@sirugh sirugh left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
pkg:peregrine pkg:venia-concept version: Minor This changeset includes functionality added in a backwards compatible manner.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

[BUG] Cropped shopping cart in Venia for larger phones
5 participants