Open mst-kialo opened 10 months ago
Suppressing the scrolling on focus is done because browsers tend to eagerly scroll the top of the document into view on focus, which is wrong when the selection is somewhere else. The question is whether EditorView.focus
should explicitly scroll the (actual) selection into view, or if that will be a problem for people who have come to rely on it not doing that. And whether that would even help here. Does something like view.dispatch(view.state.tr.scrollIntoView())
after focusing improve the situation for you?
Does something like view.dispatch(view.state.tr.scrollIntoView()) after focusing improve the situation for you?
Unfortunately that does not seem to have any effect. The software keyboard is still hiding the input field.
I'm experiencing the same thing. Calling EditorView.dom.focus()
fixes the issue but it basically bypasses everything that is done inside EditorView.focus
. I don't think that that is ideal. The suggested solution above hasn't worked for me either. Any further suggestions?
Just to add, I can confirm that this only affects iOS. Android is unaffected.
Here's a video of the issue (It's a web app running in a WebView): https://github.com/ProseMirror/prosemirror/assets/10741084/a87cd9cd-43fc-468e-a7ce-677143b09a1c
First off please excuse if this is already a known issue but I was not able to find anything about it here. Basically calling EditorView.focus causes the onscreen keyboard of iOS devices to overlap the inputfield on Safari making it hard to see what is being entered. This does not seem to happen with other browsers used on iOS as far as I could test. My assumption is that the correct behaviour would be for the keyboard to push up everything as to not obstruct the field.
This can be easily seen in the demo here provided by someone else: Demo The overlap does not happen when clicking into the input directly or using EditorView.dom.focus which is why I assume the reason lies somewhere in the focusPreventScroll call made in .focus.