tallwhitey

Thanks for the thought, but after testing, the vh and vw only change on android devices as I thought. Seems the only way to account for it is to know the actual height of the keyboard for each apple device, which also seems problematic as I'm unaware of anyway of detecting if the user has a 3rd party keyboard installed. And even then, I'm not sure it allows you to programtically scroll while an input is selected. Thanks though for the help.

Update: Turns out this is a webkit bug introduced in iOS 11. The virtual keyboard is not accounted for taking up any space, so the innerHeight and other measures of the size of the viewport aren't accurate. There is a webkit bug reported but not sure how long those take to fix. And don't really see any way sidestep this since you can never know the actual size of the viewport until they remedy it.

I determined more specifically what is happening. If trying to use the ScrollTo plugin to scroll the window up while an input is focused, it thinks the bottom of the viewport is at the bottom of the keyboard rather than the top of it. Is there any way to fix this?

TLDR: In iOS 11, if using scrollTo plugin for the window while an input is focused, it thinks the bottom of the mobile keyboard is the bottom of the viewport rather than the top of the keyboard, thus hiding any inputs located at the very bottom of a page. Any Greensock fixes? I discovered this error due to iOS's 3rd-party keyboards not accounting for the input selector bar on top of the mobile keyboard when determining the bottom of the viewport while an input is focused located at the bottom of the window, thus blocking the view of the input. What seems to be happening is if the window element is moved using scrollTo while an input is focused at the very bottom of the window, the correct positioning is not scrolled to. This is the case mainly for values that exceed the height of the window, and subsequently effects using the scrollTo Plugin when using scrollTo:"max" I know you all can't fix the iOS issue, but since its affecting the plugin, is there any workaround to account for when an input is selected such as a chat entry box at the bottom of the screen, and have the plugin scroll to the bottom of the screen properly? I've included a codepen, but only works in debug mode since there was already an issue you all found with scrolling in iOS in iframes. Thanks! https://s.codepen.io/tallwhitey/debug/gozWWQ/VGrWNnabZVaM

My site was experiencing issues using the scrollTo plugin with the window element on ios devices after i installed the latest update 11.1 (iphone 6s plus). In order to determine if it was conflicting with anything else, I instead looked for previous codepens. And confirmed that the one linked is also not working on ios devices but does on desktop and android. Is this a known bug again? or any workarounds for this in the meantime?

As you can see in the codepen, the <br> tags work as expected going forward. But all text changes besides the final one, don't recognize the break tags as needed.

Thanks for the quick response as this seems to be the best forums I've ever come across! And yes the allowNativeScrolling:false seemed to do the trick. So obviously some conflict there. I felt I had to use ScrollTop because I was getting very poor performance on an iphone 6s I was testing. Most likely a result of how my app is setup, but the address bar kept overriding things. Thanks again for the suggestion!

I'm encountering an issue whereby I have a div assigned a draggable {type:"scrollTop"}. Within that div are other elements assigned a Draggable {type:"x"}. The problem comes when trying to swipe the child elements right and left. It usually triggers on the first attempt, but during any vertical movement, the parent div and all its other elements start to jitter unexpectedly very minutely in the vertical direction. And then the type x elements become difficult to trigger in the horizontal movement again. (all this on mobile android) Things work fine though when I change the parent div to a type:"y". Any ideas what is the cause? and/or solution?

Thanks for the thorough response. The only issue is that I was looking for a way to only remove tweens with an explicit label, and not other tweens that happen to land at the same time (which happens when I changed the gray box to start .5 early). Hopefully I'll have time to look more into it later this evening. Thanks!

Yeah I assumed this was a very edge case but it appealed to the "is it possible" part of me

Even more impressive would be if you were able to tween out the gap, by either running all children behind the removal forward for the duration while keeping the children before it paused. Or vice versa.

I've looked in the docs but haven't been able to find a straightforward way. But is it possible to simply remove a tween from a Timeline using it's position label? And a sort of side question, if a Timeline has 3 tweens (each 1 second long), one at the start, 1 sec, and 2 seconds in, and you remove the middle one, does the 3rd tween shift to start at 1 second, or remain at 2? Thanks.

Hey guys, Anyone able to look at this? (The original link does in fact work now). I'm ready to upgrade to get SplitText, but if this issue can't be figured out for Safari in IOS, its a moot point. I suspect it has something to do with the address bar resizing in Safari thats causing the item to disappear at the end of the tween. Any help would be appreciated. Thanks.

So here is a stripped down version of just the scrolling effect. Im not sure if will reproduce the effect on mobile safari though, but thats at least the javascript code I used for it. With a few exceptions from calculations I had to make to compensate for Edge's responsive scaling feature. http://codepen.io/anon/pen/ZGZzWz

I apologize. I was trying on internet explorer and the link adds those characters. The real issue looks to be the httpS. Remove the s and that should do the trick. Once again, I'll add the codepen as soon as I'm back to that computer to try and reproduce on there.