Verify that pinning works on mobile

[colinmorris]

It doesn't seem to work using chrome's mobile emulator, but it does work with $force_mobile = true. I'm hoping it will turn out to work when tested on an actual mobile device.

[colinmorris]

Bleh. Just tested on my phone and it seems genuinely broken. I fear this is some obscure ScrollMagic bug.

[colinmorris]

Thinking out loud here: the weird thing is that I can't reproduce this on desktop if I just shrink my browser window to be really small. So it's got to be some kind of intrinsic difference between scroll events on mobile devices vs. desktop.

Setting loglevel: 3 on the outer scene (in story.js) gives debug-level updates in the console as you scroll, e.g.

14:22:11:548 (ScrollMagic.Scene) -> event fired: update -> {startPos: 929, endPos: 22889, scrollPos: 845}

Based on that, it seems like a couple weird things happen on mobile:

1. Scroll updates seem to randomly drop or get delayed for long periods

2. The numbers don't make sense. e.g. when I scroll the top of the story element to the top of the viewport (the point at which the scene should begin) the logging says:

   14:24:43:763 (ScrollMagic.Scene) -> event fired: update -> {startPos: 1052, endPos: 38655, scrollPos: 712}

Based on the heights of the .intro and .prose elements at the start, it seems like startPos is accurate. So for some reason ScrollMagic is underestimating the distance that I've actually scrolled?

[colinmorris]

This probably explains the delayed updates (which seem relatively innocuous): http://scrollmagic.io/examples/advanced/mobile_basic.html

[colinmorris]

window.pageYOffset agrees with ScrollMagic?! The plot thickens.

[colinmorris]

The problem seems to be specifically that on mobile, no change is registered to window.scrollY until after p#intro-text (i.e. it's treating the document as beginning after that element).

Which is... really weird

[peterwgnd]

Sorry for the late chime in here. Just escaped a meeting. Are you still seeing this? I'm cheating here by using the mobile emulator in Chrome, but if I console log window.scrollY it seems to pick up there right from the outset

[colinmorris]

Yup, still seeing it. What I'm doing to repro it is:

1. Open mobile emulator in chrome (I'm using Nexus 5x as the device)
2. Refresh until it 'looks right' (I'm not sure why, but sometimes I need to do this a few times or do a hard reload before it seems to properly respond to the new viewport dimensions)
3. Scroll to the top
4. In the console, type window.scrollY, get 0
5. Scroll down a little bit and repeat. I still see 0.
6. Continue until scrolling past the intro paragraph (above the author info). Only then does window.scrollY start becoming positive.

[colinmorris]

(Also, if you want to see the manifestation of this bug, just open https://colinmorris.github.io/atypicality/ on your phone and scroll down to the radar chart. At least on my device running mobile chrome, the radar chart doesn't get pinned until far too late)

[colinmorris]

I'm also seeing a bunch of cases where, after scrolling past the 0-point, scrollY seems to get stuck for a while at a certain positive value (waiting doesn't seem to cause it to change, but if I scroll enough, it eventually unsticks).

[colinmorris]

One suspicion I had was that this was some kind of ScrollMagic bug, where it was intercepting scroll events and doing weird things with them, but that doesn't seem to be the case. If I comment out the ScrollMagic imports from my js files, I still see the same thing.

[colinmorris]

I just tried the site in Firefox (first the mobile emulator then on my phone), and it's totally fine. So I guess whatever this is is Chrome-specific. :thinking:

[peterwgnd]

Huh. I failed to refresh last time after opening the emulator. Noted the weirdness with the text only taking up about 1/2 of the viewport but honestly didn't think much of it (just assumed there was a width declaration that was constraining it somewhere). Have checked it in Safari on iPhones and it seems to work as expected. Trying to hunt down an Android device.

[colinmorris]

This fixed it! https://stackoverflow.com/a/44680066/262271 (Now I'm really curious to dig into why)

[peterwgnd]

Fantastic! So odd that it seems to be specific to Chrome on Android. Works perfectly fine on Chrome on an iPhone without that addition

[colinmorris]

TIL about visual vs. layout viewports: https://developers.google.com/web/updates/2017/09/visual-viewport-api

As it turns out...

• window.visualViewport.pageTop gives the scroll position I'm looking for
• window.visualViewport.pageTop == window.visualViewport.offsetTop + window.scrollY

Basically what this means is that for the first 448 pixels of scrolling or so, the layout viewport (whose position is given by window.scrollY) is fixed, and the visual viewport is moving down within the layout viewport, until the bottom of the visual viewport meets the bottom of the layout viewport.

All this is because the layout viewport is much taller than the visual viewport.

> window.visualViewport.height
667.0000610351562
> window.visualViewport.width
375.0000305175781
> window.innerHeight
1116
> window.innerWidth
627

In this case, Chrome is supposed to be emulating an iPhone 7 with dimensions 375 x 667. So where the heck do 1116 and 627 come from?

window.visualViewport.scale seems like a likely culprit, especially since the whole solution to this mess was basically to disable pinch-zoom by setting user-scalable=no. But nope, window.visualViewport.scale == 1.

So at this point I'm at a loss for further explanation. :man_shrugging: :man_shrugging: :man_shrugging: :man_shrugging: :man_shrugging: :man_shrugging: