|
Post by fnllc on May 13, 2019 16:44:17 GMT
There is a bug in iOS affecting WebView apps such as Rhomobile / Cordova / React Native that causes the WebView Viewport to be shifted up after the keyboard is dismissed when using the metatag "viewport-fit=cover" to handle the iPhone notches. I'm currently using the latest Rhomobile 6.1-stable-branch and Framework7 4.3.1 and encountered this problem. Cordova has a thread about this issue: github.com/apache/cordova-ios/issues/417React Native has PR that I tried to add on Rhomobile and it seems to work: github.com/react-native-community/react-native-webview/pull/296/filesI made the changes to RhoWkWebView.m The only issue is that it crashes when it needs to invalidate the timer. The error is 'invalid thread': -(void)keyboardWillShow { if (keyboardTimer != nil) { [keyboardTimer invalidate]; } } I don't have enough experience with XCode to figure this out. It might be good to add this fix in Rhomobile as well. Reference to actual bug: openradar.appspot.com/radar?id=5018321736957952
|
|
|
Post by jontara on May 15, 2019 22:32:49 GMT
I don't know if this will help you, but from iOS 11 there are CSS constants defined in the webview for all of the "safe areas".
I use full-screen, but put a transparent "spacer" div at the top of the screen, which equals the height of iOS system status bar, any safe area (depending on device) and any fixed-height page header. My content scrolls "under" all of this. The spacer insures that the content lines-up just below the fixed header when scrolled to top.
You will have to make use of the new CSS constants in a way that makes sense for your app layout. Google for 'safe-area-inset CSS'
I do something like this (SCSS):
.os_status_bar_spacer { margin: 0; padding: 0; width: 100%; height: $ios_status_bar_height; height: constant(safe-area-inset-top); // < ios 11.2 height: env(safe-area-inset-top); // >= ios 11.2 }
.app_header_spacer { height: calc(#{$ios_status_bar_height} + #{$header_height}); height: calc(#{$header_height} + constant(safe-area-inset-top)); height: calc(#{$header_height} + env(safe-area-inset-top)); background-color: white; // Otherwise, page background changes header color // Of course, it will still header color when page is scrolled }
.is_in_call { .os_status_bar_spacer { height: $ios_status_bar_height_incall; } .app_header_spacer { height: calc(#{$ios_status_bar_height_incall} + #{$header_height}); height: calc(#{$header_height} + constant(safe-area-inset-top)); height: calc(#{$header_height} + env(safe-area-inset-top)); } }
|
|
|
Post by jontara on May 15, 2019 22:52:45 GMT
Note: the safe-area-inset-top INCLUDES the height of the iOS status bar. $ios_status_bar_height (you have to define this constant - it is 20px, unless in-call, when it is 40px). For iOS 10, there is no definition of safe-area-inset-top, so the value of $ios_status_bar_height will be used. For iOS 11, Apple used the deprecated CSS constant() For iOS >= 11.2, Apple adopted the standard CSS env() which does the same thing as constant() See: css-tricks.com/the-notch-and-css/
|
|
|
Post by fnllc on May 16, 2019 19:10:46 GMT
Thanks Jon. Framework7 already handles all this as you describe. It can't be fixed with CSS, because it's the WebView itself that gets shifted.
I only noticed this issue when I enabled the soft keyboard in the simulator. By default, it doesn't show the keyboard. You also need to be compiling with the iOS 12 SDK. No problem with the iOS 11 SDK.
Are you not experiencing the same issue? It seems to be a widespread issue for Cordova, React Native, etc...
|
|
|
Post by jontara on May 21, 2019 2:47:39 GMT
Ohhhhh! THAT problem! Now I understand. It's the ScrollView that holds the UIWebView that causes this.
I actually have a native extension that I wrote to fix this. It has some other nice features, such as providing keyboardWillShow, keyboardDidShow, etc. callbacks.
It would need to be brought up to date though. It has ios version-specific hacks. I haven't had a need recently, as I haven't done anything with a lot of forms recently. (It was done for an app that had a large number of complex forms.) I don't have anything more complicated than a login form with my current work.
Let me see if I have permission to put this on GitHub.
|
|