Ckeditor5: [iOS] [Webview] Caret goes offscreen while typing
Is this a bug report or feature request? (choose one)
🐞 Bug report
💻 Version of CKEditor
11.1.1, any of the presets.
📋 Steps to reproduce
So we offer email functionalities within our React-Native app and while this works perfectly on Android, we are having issues with automatic scrolling on iOS when typing. (Note that a enter linebreak does work properly but continous typing goes off screen.)
I realise this might not be directly a bug of CKEditor, but I am desperate to figure out a solution as there are currently no proper rich text editors for react-native.
📃 Other details that might be useful
React-Native implementation details to reproduce.
RN version: 0.56
Render method:
(Note this is not RN's Webview due to us needing WKWebview and React-native only supporting it since RN 0.57. https://github.com/CRAlpha/react-native-wkwebview)
render() {
return (
<KeyboardAvoidingView
style={{ flex: 1 }}
behavior="padding"
keyboardVerticalOffset={65}
>
<WKWebView
ref={(ref) => { this.webView = ref; }}
style={{ flex: 1 }}
hideKeyboardAccessoryView
keyboardDismissMode="on-drag"
allowsBackForwardNavigationGestures={false}
source={webapp}
onMessage={this.onMessage}
/>
</KeyboardAvoidingView>
);
}
The actual html we load:
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<meta name="viewport" content="initial-scale=1.0, user-scalable=no" />
<title>CKEditor 5 – Classic editor</title>
<script src="https://cdn.ckeditor.com/ckeditor5/11.1.1/decoupled-document/ckeditor.js"></script>
<script>
function postData() {
window.postMessage(window.editor.getData())
}
</script>
</head>
<body>
<!-- The toolbar will be rendered in this container. -->
<div id="toolbar-container"></div>
<!-- This container will become the editable. -->
<div id="editor">
<p>This is the initial editor content.</p>
</div>
<script>
DecoupledEditor
.create( document.querySelector( '#editor' ) )
.then( editor => {
var toolbarContainer = document.querySelector( '#toolbar-container' );
toolbarContainer.appendChild( editor.ui.view.toolbar.element );
window.editor = editor;
editor.model.document.on( 'change:data', () => {
postData();
});
} )
.catch( error => {
console.error( error );
} );
</script>
</body>
</html>
ItsNoHax
All 10 comments
I think this was a native issue of this platform. Didn't we have it reported already, @Mgsy?
Reinmar
on 24 Oct 2018
I think this was a native issue of this platform. Didn't we have it reported already, @Mgsy?
I believe we didn't report it, but this one looks like the iOS issue. It could be reproduced in our editor, i.e. on ckeditor5.github.io or in a simple textarea - https://jsfiddle.net/9yub58ft/.
Works fine on Android.
Mgsy
on 25 Oct 2018
OK, so this is an upstream issue. I just tried this in native contentEditable too and it was completely broken. I tested a couple other editors and it wasn't working too.
It's strange, though. I don't think this bug existed. It may be new. We should report it to Apple.
@Mgsy could you create samples with bare textarea and bare contentEditable element and record screencasts of what's happening?
Reinmar
on 29 Oct 2018
@Reinmar @Mgsy Let me know if there is anything I can do to help. This is a real show stopper for me.
And I don't believe this is new, we had the same issue with CKEditor 4.
ItsNoHax
on 31 Oct 2018
This could be because our view.scrollToTheSelection() method executed upon enter, backspace or paste. As long as the user is typing, the native positioning works but when they hit enter/backspace, our method kicks in and moves the viewport. This works properly on desktop but since the mechanics of the iOS viewport when the software keyboard is visible is weird it could be that scrollToTheSelection does more harm than good.
oleq
on 31 Oct 2018
@Mgsy could you create samples with bare textarea and bare contentEditable element and record screencasts of what's happening?
I've prepared a sample with those elements. And here is a screencast, so you can check the behaviour in textarea and contenteditable elements.
Recorded on iPad@iOS 12.0.
Mgsy
on 31 Oct 2018
@Mgsy @oleq @Reinmar
Is there any sort of temporary workaround that I could use for now? I believe the Medium iOS mobile app does some sort of workaround in their editor. If you create a post and type past the end you can see it triggers some sort of scroll event manually.
ItsNoHax
on 1 Nov 2018
On the desktop, this would help:
editor.editing.view.on( 'render', () => {
editor.editing.view.scrollToTheSelection();
}, { priority: 'low' } );
I'm testing it in Chrome with a code like this and every time "foo" is inserted into the editor, the viewport is properly scrolled to show the caret:
setInterval( () => {
editor.model.change( writer => {
editor.model.insertContent( writer.createText( 'foo' ) );
} );
}, 2000 );
(DEMO: https://jsfiddle.net/tsf7mxd4/1/)
It has to be tested with an action which would not natively scroll the content, so not with the native typing because on all browsers (except Safari@iOS) typing does scroll the viewport.
So, the above demo works fine in Chrome and Safari@macOS and Chrome@Android.
But on iOS it does not work. Why? Because the viewport mechanics is broken there when the software keyboard is visible. That's an old issue (https://github.com/ckeditor/ckeditor5-design/issues/149) that we tried to interest people about, but with no luck so far. However, just recently I talked with @whsieh on W3C TPAC that perhaps this could be fixed. I'm actually working on filing bug reports for that right now.
Anyway, to sum up, right now we can see that there are two issues:
- Viewport mechanics when the software keyboard is visible. This one is old. Reported in: https://bugs.webkit.org/show_bug.cgi?id=191204
- No scrolling on typing. This one seems to be a recent regression in Safari. Reported in: https://bugs.webkit.org/show_bug.cgi?id=191185
Reinmar
on 2 Nov 2018
@Reinmar Thanks for the detailed reply. I'm a bit hesitant it will be fixed in the short term since the first time this bug was reported was in 2016 according to the openradar link
ItsNoHax
on 5 Nov 2018
Apple rarely shares their plans regarding such issues. The best solution, IMO, for now, would be to get as many developers as possible leaving feedback under https://bugs.webkit.org/show_bug.cgi?id=191185 regarding the severity of this issue. Since it's considered a regression, I think there's not much doubt that it's doesn't work as intended now, so the only problem should be properly prioritising it.
Reinmar
on 5 Nov 2018
Related issues
jodator
·
3Comments
pandora-iuz
·
3Comments
wwalc
·
3Comments
wwalc
·
3Comments
Reinmar
·
3Comments
Most helpful comment
OK, so this is an upstream issue. I just tried this in native contentEditable too and it was completely broken. I tested a couple other editors and it wasn't working too.
It's strange, though. I don't think this bug existed. It may be new. We should report it to Apple.
@Mgsy could you create samples with bare textarea and bare contentEditable element and record screencasts of what's happening?