Do you want to request a feature or report a bug?
It is a safari bug, but may be work around in draft-js.
What is the current behavior?
On ios11 safari, contenteditable="false" inside contenteditable="true" get focused when click on it.
Currently, draft-js wraps all blocks inside one div that has contenteditable="true". Atomic blocks have contenteditable="false", but is ignored by safari. When users click on an atomic block, though they can't edit it, keyboard is shown.
If the current behavior is a bug, please provide the steps to reproduce and if possible a minimal demo of the problem. You can use this jsfiddle to get started: https://jsfiddle.net/stopachka/m6z0xn4r/.
Try this example: http://jsbin.com/butunupunu/edit?html,output
Which versions of Draft.js, and which browser / OS are affected by this issue? Did this work in previous versions of Draft.js?
Draft-js v10.4. Safari on ios11, ipad.
@blackChef thanks for reaching out. Not sure what we can do about it tbh 馃槩
For anyone who's struggling with this issue, I found a solution:
Add onTouchStart handler to your custom block. And in that handler, first we set wrapper's contentEditable to false then reverse it after a shot period.
onTouchStart() {
document.querySelector('.public-DraftEditor-content')
.contentEditable = false;
setTimeout(function() {
document.querySelector('.public-DraftEditor-content')
.contentEditable = true;
}, 100);
},
Most helpful comment
For anyone who's struggling with this issue, I found a solution:
Add
onTouchStarthandler to your custom block. And in that handler, first we set wrapper'scontentEditabletofalsethen reverse it after a shot period.