You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cordova.apache.org by GitBox <gi...@apache.org> on 2019/09/23 18:50:59 UTC
[GitHub] [cordova-plugin-statusbar] breautek commented on issue #128:
CB-13300: (Android) Fixed keyboard from overlapping content
breautek commented on issue #128: CB-13300: (Android) Fixed keyboard from overlapping content
URL: https://github.com/apache/cordova-plugin-statusbar/pull/128#issuecomment-534233923
Sure thing @purplecabbage
For context I'll provide 2 before screenshots, and 1 after. This is using cordova-android `8.1.0` and using statusbar version `^2.4.2`. The test app I used for these screenshots can be found [here](https://github.com/tharunkumar0/test) This screenshot below is the screen with no keyboard shown. The Textfield is positioned absolutely using CSS `bottom: 0px;`, so it is always displayed at the bottom edge of the webview.
The next screenshot is when the text field receives focused. Note how the textfield isn't in view. It is impossible to have the textfield in view in this case with how the webview works without this PR changes.
This next screenshot is with this PR statusbar changes. The textfield is now in view. This works because the webview native UI physically is resized to fit the screen real estate. So in this screenshot, the bottom of the webview is exactly where the keyboard starts. I've added a new class `StatusBarViewHelper` that watches the native UI nodes for geometry changes, and it resizes the webview accordingly so that the webview always fills the screen space minus the status bar (if solid), the navigation bar (for phones without physical buttons), and the keyboard.
Note that if your HTML is configured in a way where you define a fixed height for your document. If the webview resizes smaller than that document size it will make the webview scrollable (assuming you allow it via the `overflow` css). This is exactly the issue I had as without this PR, the webview would never be scrollable as the webview never resized when the keyboard is displayed.
In theory, if the user has custom keyboards installed with different potentially different sizes, this PR should just work as well.
Additionally this PR makes the android webview behave a lot like the iOS webview, where by default, iOS just seems to handle things more intelligently when the keyboard is opened because they also do resize the webview.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
With regards,
Apache Git Services
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscribe@cordova.apache.org
For additional commands, e-mail: commits-help@cordova.apache.org