Jump to content
GreenSock

Search In
  • More options...
Find results that contain...
Find results in...
tallwhitey

ScrollTo plugin for iOS error while focus

Recommended Posts

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

See the Pen gozWWQ by tallwhitey (@tallwhitey) on CodePen

Link to comment
Share on other sites

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?

Link to comment
Share on other sites

  • 3 weeks later...

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.

  • Like 2
Link to comment
Share on other sites

Thanks for reporting back about the problem. And yeah, I know how annoying it is when a browser has a bug that's basically impossible to work around. Ugh! Wish I had a silver bullet for ya. 

 

Probably won't work, but here's a weird idea: what if you put an invisible <div> into the DOM that's sized to the viewport (like 100vw and 100vh or % or whatever) with visibility:hidden and then query its offsetWidth/offsetHeight or something like that? 

  • Like 1
Link to comment
Share on other sites

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.

 

 

  • Like 1
Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×