Scroll cursor onscreen if needed on text entry, arrow key use or rotation. #2842
Conversation
| wmf.commands = { | ||
| keyboardHeightChanged: (newHeight) => { |
There was a problem hiding this comment.
Didn't find a way to determine that the keyboard appeared purely from JS land... thought maybe the viewport dimensions would change or something. In native land adjustedContentInset changes as the keyboard's size changes, but didn't see anything in JS land that tracks with that change. If we had a way to directly or indirectly determine changes to keyboard height from JS land we wouldn't need this keyboardHeightChanged message from native land or even the resize listener I added. There's a chance I may have missed something...
There was a problem hiding this comment.
You could monitor changes to adjustedContentInset with the UIScrollViewDelegate method scrollViewDidChangeAdjustedContentInset instead of the keyboard notification and it'd take into account any overlays that aren't the keyboard (for example if the edit toolbar moves into the view itself to keep it visible even after the keyboard is dismissed). You could also pass the full insets to JS to account for any overlays we'd add to the top.
montehurd
changed the title
|
Added WIP tag - found a bug. |
| @@ -46,6 +48,18 @@ class SectionEditorViewController: UIViewController { | |||
| apply(theme: theme) | |||
|
|
|||
| WMFAuthenticationManager.sharedInstance.loginWithSavedCredentials { (_) in } | |||
|
|
|||
| NotificationCenter.default.addObserver(forName: UIWindow.keyboardDidChangeFrameNotification, object: nil, queue: nil, using: { [weak self] notification in | |||
There was a problem hiding this comment.
This observation is never removed, so even though self is weak, it continues to fire with self as nil even after the VC is deallocated.
There was a problem hiding this comment.
Ah thx. We may have same issue in ViewController.swift. I can fix it there when I fix this.
| wmf.commands = { | ||
| keyboardHeightChanged: (newHeight) => { |
There was a problem hiding this comment.
You could monitor changes to adjustedContentInset with the UIScrollViewDelegate method scrollViewDidChangeAdjustedContentInset instead of the keyboard notification and it'd take into account any overlays that aren't the keyboard (for example if the edit toolbar moves into the view itself to keep it visible even after the keyboard is dismissed). You could also pass the full insets to JS to account for any overlays we'd add to the top.
…arance for determining portion of webview covered by keyboard
https://phabricator.wikimedia.org/T213452
Ensures text insertion point is onscreen when...
NOTE: there is a simulator-only bug: if you scroll down, then tap the up arrow key on your keyboard repeatedly until the cursor moves off the top of the screen, it will jump back down in jarring way. Is sim-only because it doesn't happen if you're on device and using the
^button instead of the up arrow keyboard key (which doesn't exists on device).