EditorView.focus on iOS causes the onscreen keyboard to overlay the editor. #1417

Open
opened 2023-10-05 13:10:11 +02:00 by mst-kialo · 3 comments
mst-kialo commented 2023-10-05 13:10:11 +02:00 (Migrated from github.com)

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.

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](https://codepen.io/alexaaaant/pen/mdaJwLp) 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.
marijnh commented 2023-10-06 16:44:28 +02:00 (Migrated from github.com)

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?

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?
mst-kialo commented 2023-10-09 13:40:37 +02:00 (Migrated from github.com)

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.

> 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.
vickz84259 commented 2024-01-11 19:00:05 +01:00 (Migrated from github.com)

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

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
Sign in to join this conversation.
No labels
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
prosemirror/prosemirror#1417
No description provided.