Safari on ios11 ignores contenteditable="false" inside contenteditable="true"

[blackChef]

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.

[juliankrispel]

@blackChef thanks for reaching out. Not sure what we can do about it tbh 😢

[blackChef]

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);
},