ScrollTrigger 100vh Calculation Change in 3.12.2

[BaskingShark]

In 3.12.2 there was a change made to the way ScrollTrigger calculates the viewport height:

 

Quote

- IMPROVED: on mobile devices where the address bar shows/hides and sometimes causes a jump after scrolling stops, particularly if there are multiple pins, ScrollTrigger now calculates positions based on 100vh instead of window.innerHeight because the former doesn't change whereas the latter does. This essentially avoids the "jump" in most cases (unless the elements on your page actually resize).

 

While it's great trying to remove some of the "jumps" in mobile with the show/hide behavior of the address bar, this was a breaking change for me since the new method makes it almost impossible to fire triggers properly based on the bottom of the visible viewport or to pin items that are set to take up the full viewport space by using JS hacks like the one described here https://css-tricks.com/the-trick-to-viewport-units-on-mobile/

I don't have a perfect solution, since mobile browser height is an absolute mess, but I still need a way to pin and trigger elements based on the perceived viewport, including the address bar, not the actual one that is the height of the browser window. While I know that 100vh is technically correct, the users just see that pins are getting cut off at the bottom or not firing. Would it be possible to add a new option to select the way that mobile browser height is calculated? Right now I'm frozen at v3.12.1 since I have several designs that call for perceived viewport height pins on mobile.

[GreenSock]

Sorry about the hassle there, @BaskingShark. Do you have a minimal demo that illustrates the broken behavior (pins getting cut off or not firing)? That'd be super helpful. 

[BaskingShark]

So here't the thing: after banging my head against CodePen for a couple hours trying to reproduce what I'm seeing, I realized I can't make a demo there for you. CodePen sets the body of the document to 100vh with overflow: hidden and then wraps the user content in an iframe with 100svh, effectively insulating the GreenSock code from any mobile browser height issues. It's sort of a built-in normalizeScroll().

 

I can show you a page in production using v3.12.1 that works correctly: https://poply.com/event_templates/76/preview

 

and highlight the code that GreenSock adds to pin the top section:

<div id="template_intro" class="template_intro">
  <div class="pin-spacer" style="order: 0; align-self: auto; justify-self: stretch; grid-row-start: auto; grid-column-start: auto; grid-row-end: auto; grid-column-end: auto; z-index: auto; float: none; flex-shrink: 1; display: grid; margin: 0px; inset: auto; position: relative; flex-basis: auto; overflow: visible; box-sizing: border-box; width: 390px; height: 664px; padding: 0px;">
    <div id="template_intro_wrapper_outer" class="template_intro_wrapper_outer" style="translate: none; rotate: none; scale: none; left: 0px; top: 0.001px; margin: 0px; max-width: 390px; width: 390px; max-height: 664px; height: 664px; padding: 75px 0px; box-sizing: border-box; position: fixed; transform: translate(0px, 0px);">
      <!-- content -->
    </div>
  </div>
</div>

then compare that with the code that's added with no other change than upgrading to v3.12.2:

<div id="template_intro" class="template_intro">
  <div class="pin-spacer" style="order: 0; align-self: auto; justify-self: stretch; grid-row-start: auto; grid-column-start: auto; grid-row-end: auto; grid-column-end: auto; z-index: auto; float: none; flex-shrink: 1; display: grid; margin: 0px; inset: auto; position: relative; flex-basis: auto; overflow: visible; box-sizing: border-box; width: 390px; height: 664px; padding: 0px;">
    <div id="template_intro_wrapper_outer" class="template_intro_wrapper_outer" style="translate: none; rotate: none; scale: none; left: 0px; top: 81px; margin: 0px; max-width: 390px; width: 390px; max-height: 664px; height: 664px; padding: 75px 0px; box-sizing: border-box; position: fixed; transform: translate(0px, 0px);">
      <!-- content -->
    </div>
  </div>
</div>

The only difference is the "top: 81px" on "template_intro_wrapper_outer" -- the height of the address bar in mobile safari -- that's included by the newer code and that's what throws off the rest of the page. It basically moves all my content down and makes the footer inaccessible since I have to wrap the page in overflow: hidden to accommodate other animations.

 

I do have normalizeScroll set to true for mobile browsers to make this complicated layout work, so I'm wondering if that's the issue. Maybe a better solution would be to have ScrollTrigger use 100svh in calculating height when normalizeScroll is true, and 100vh when false.

[GreenSock]

Sorry about the delay, @BaskingShark. With all the excitement and flurry of activity leading up to the launch of the new site/brand, this slipped through the cracks but I think your suggestion is a good one (to handle it differently when normalizeScroll() is enabled). Can you try this beta file and confirm that it works well for you? 

https://assets.codepen.io/16327/ScrollTrigger.min.js

[BaskingShark]

My turn to apologize for the delay -- we had our own launch that took over for awhile. I finally got a chance to test out your beta and it works great! It solves the problems I was having on mobile with viewport height without compromising on desktop. Thanks!!