slate: Chrome 105 breaks slate 0.27.x

Description Our application (an electronic health record) uses slate in production; versions:

    "slate": "0.27.4",
    "slate-auto-replace": "0.8.1",
    "slate-react": "0.7.2",

The update to Chrome 105 now rolling out breaks the ability for slate to find a DOM point, it looks like.

In the above screenshot you can see that leaf will be null as end is zero and point.offset is 2, meaning the condition of end >= point.offset will never be satisfied.

I realize we’re on an old version of slate but if there’s a known fix for Chrome 105 issues or a link to crbug for whatever the regression is there we would be very grateful.

Recording Will follow up with a GIF.

Environment

Slate Version: 0.27.4
Operating System: macOS
Browser: Chrome 105

About this issue

Original URL
State: open
Created 2 years ago
Reactions: 8
Comments: 36 (9 by maintainers)

Commits related to this issue

Fix jumping cursor bug in Chrome 105 Override the `-webkit-user-modify: read-write-plaintext-only` style that is added by slate to the editor element that causes a cursor jumping bug in Chrome 105. ... — committed to UKHomeOffice/asl-projects by lennym 2 years ago
Fix slate issue caused by Chrome 106 Was able to determine that this was the problem by bisecting our Electron upgrade and identifying which chrome version bump broke it, and then googling for slate ... — committed to Foundry376/Mailspring by bengotow 7 months ago

Most upvoted comments

@beaugunderson

OMG! I can’t believe that all the issues in Chrome 105 described in my previous comment here were because of style WebkitUserModify: 'read-write-plaintext-only' on contentEditable container.

After some deep investigation, I realized that event.getTargetRanges() returns an empty array in onBeforeInput handler in after plugin when that WebkitUserModify style applied. In this case onBeforeInput handler returns and does nothing, so that you can see onInput event handler works instead as a fallback that leads to some unexpected behaviour in my cases.

Please check it out for your case - it might be the root of the issue you are experiencing.

+11

zarv1k on Sep 2, 2022

@ThomasEsseul

My team published a hotfix with the WebkitUserModify solution, it seems to work fine ! But we have some users (Mac + Chrome 105+ users only) who experience problems when typing some specific special characters (i.e. ê, â, ï, ô… 🥖). Did anyone hear about such a case on their side ?

Yes, we meet the exact same problem with ê, â … characters.

@Slapbox

Is anyone not able to get their editor working with the provided workarounds?

We applied the -webkit-user-modify fix but still have problems with accented characters.

Does anyone knows a fix around this particular issue?

bobey on Oct 6, 2022

@beaugunderson

OMG! I can’t believe that all the issues in Chrome 105 described in my previous comment here were because of style WebkitUserModify: 'read-write-plaintext-only' on contentEditable container.

After some deep investigation, I realized that event.getTargetRanges() returns an empty array in onBeforeInput handler in after plugin when that WebkitUserModify style applied. In this case onBeforeInput handler returns and does nothing, so that you can see onInput event handler works instead as a fallback that leads to some unexpected behaviour in my cases.

Please check it out for your case - it might be the root of the issue you are experiencing.

Hi @zarv1k. We’re experiencing the exact same problems that you mentioned in the previous comment. And changing the style on contentEditable from WebkitUserModify: 'read-write-plaintext-only' to WebkitUserModify: 'read-write' fix every issue we got so far.

I’m wondering if this is the best workaround for now, or do you have a better way to solve this?

fikrikarim on Sep 2, 2022

Hi there… just in case it helps anyone the way we fixed this was to execute this code on a <head> <script>

delete HTMLElement.prototype.onbeforeinput

on Google Chrome 105+ they added a new way of setting the beforeinput event, now you can also set is as a DOM element attribute (just like <a onclick="" />)

so precisely, slate was detecting on which input event level the browser is at… by detecting if any given DOM element supports the beforeinput attribute.

So with this fix… we make slate think that Chrome 105+ and Chrome < 105 are in the same input event level

there is a side effect which is that you won’t be able to define a beforeinput event as a dom element attribute but… well 🤷

nbarrera on Oct 31, 2022

Hi all,

I’d like to thank everyone here who shared feedbacks and tips to help fix this issue.

Just to let you know that we applied all options shared here, even @mathisobadia’s one, it fixes part of the bug on our side but we still have a failure with accented characters.

If someone discover a fix for this particular issue, do not hesitate to share it 🙏

bobey on Oct 19, 2022

Ok So I thought I would explain the way I fixed this bug because some of the provided solutions did not work for us: -webkit-user-modify solution did fix the cursor thing but broke everything else. Changing the resolutions so an old slate-dev-environment didn’t work either as it broke the build.

What did work was:

install patch-package and do the required changes to your package.json to make it work
create a file named slate-react+0.22.10.patch in a folder named ‘patches’ placed at the root of your project
put this code in the newly created file:

diff --git a/node_modules/slate-react/lib/slate-react.es.js b/node_modules/slate-react/lib/slate-react.es.js
index cfb874f..af063a2 100644
--- a/node_modules/slate-react/lib/slate-react.es.js
+++ b/node_modules/slate-react/lib/slate-react.es.js
@@ -4021,7 +4021,8 @@ function AfterPlugin() {
   function onBeforeInput(event, editor, next) {
     var value = editor.value;
 
-    var isSynthetic = !!event.nativeEvent;
+    // var isSynthetic = !!event.nativeEvent;
+    var isSynthetic = true;
 
     // If the event is synthetic, it's React's polyfill of `beforeinput` that
     // isn't a true `beforeinput` event with meaningful information. It only
diff --git a/node_modules/slate-react/lib/slate-react.js b/node_modules/slate-react/lib/slate-react.js
index 6640565..b82eb19 100644
--- a/node_modules/slate-react/lib/slate-react.js
+++ b/node_modules/slate-react/lib/slate-react.js
@@ -4027,8 +4027,8 @@ function AfterPlugin() {
   function onBeforeInput(event, editor, next) {
     var value = editor.value;
 
-    var isSynthetic = !!event.nativeEvent;
-
+    //var isSynthetic = !!event.nativeEvent;
+    var isSynthetic = true;
     // If the event is synthetic, it's React's polyfill of `beforeinput` that
     // isn't a true `beforeinput` event with meaningful information. It only
     // gets triggered for character insertions, so we can just insert directly.

run yarn / npm install and that’s it

Anyway it’s really a pain to have to work on legacy code has not been upgraded since 3 years but it is what it is.

mathisobadia on Oct 13, 2022

So far, the WebkitUserModify isn’t working for us at all. Now I’m trying to explore the package resolution workaround suggested in https://github.com/ianstormtaylor/slate/issues/5108.

The fix to resolve to an earlier version of slate-dev-environment worked for us 🚀

  "resolutions": {
    "slate-dev-environment": "0.1.4"
  },

CodyJamesCasey on Sep 7, 2022

Just want to add that it’s also happening on 0.47.8. So it might be any versions before v0.50+.

FWIW, anything before 0.59 is ~2.5 to 3 years old at this point.

dylans on Sep 2, 2022

Hi there… just in case it helps anyone the way we fixed this was to execute this code on a <head> <script>

Thank you so much @nbarrera, your tips helped us temporarily fix our issue with ê, â … characters.

bobey on Nov 3, 2022

@bobey did you try forcing resolution of slate-dev-environment to an older version as mentioned by @CodyJamesCasey?

Note that the syntax @CodyJamesCasey provided is for yarn, but this can be achieved with npm/pnpm as well with the correct syntax.

Hi @Slapbox, thanks for your help on this. I tried indeed but I get a compilation error as my slate version seems to try loading a constant which is not exported anymore:

./.yarn/__virtual__/slate-react-virtual-956c00d07a/0/cache/slate-react-npm-0.22.4-d1696dbb04-f463ef2279.zip/node_modules/slate-react/lib/slate-react.es.js
Attempted import error: 'ANDROID_API_VERSION' is not exported from 'slate-dev-environment'.

Am I missing something here?

We’re using the following versions ATM:

{
  "dependencies": {
    "slate": "0.47.4",
    "slate-html-serializer": "0.8.6",
    "slate-plain-serializer": "0.7.6",
    "slate-react": "0.22.4",
    "...": "..."
  },
  "resolutions": {
    "slate-dev-environment": "0.1.6"
  }
}

bobey on Oct 7, 2022

If you want a CSS only solution to targeting Blink-based browsers (i.e. not Safari), you can use:

@supports not (-apple-trailing-word: inherit) {
  div[data-slate-editor] {
    -webkit-user-modify: read-write !important;
  }
}

stowball on Oct 5, 2022

My team published a hotfix with the WebkitUserModify solution, it seems to work fine ! But we have some users (Mac + Chrome 105+ users only) who experience problems when typing some specific special characters (i.e. ê, â, ï, ô… 🥖). Did anyone hear about such a case on their side ?

Taelar on Sep 6, 2022

FWIW, anything before 0.59 is ~2.5 to 3 years old at this point.

Point definitely taken 😃 I appreciate you leaving this open so people still on the old versions can figure out a workaround until we can upgrade (or more likely rewrite in our case since so much has changed) 🙏

beaugunderson on Sep 2, 2022

Note this does not appear to be an issue with any recent versions of Slate, only with versions released more than 3 years ago. We’ll leave this open so you can sort through it, but Slate won’t be releasing an update to a version this far back.

dylans on Sep 2, 2022

@ThomasEsseul Why some another workaround needed? Didn’t this help you? - #5110 (comment)

I have no issues in Chrome 105 using Slate 0.47.8 after I removed WebkitUserModify: 'read-write-plaintext-only' completely. But I kept it for Safari iOS, Chrome Mobile on iOS and Safari on Mac, coz it hides BIU in context menu which doesn’t work in sync with Slate.

Thank you for pointing this out. I was seeing the following bugs on slate 0.47

cursor jumps to the end of a line when I attempt to insert text in the middle of the line
bold, italics, subscript and superscript aren’t working with the textbox
placeholder text (greyed out) became real text when you clicked on it.

But now they are fixed, and I used the following modification: ...(readOnly || (!IS_IOS && !IS_SAFARI) ? {} : { WebkitUserModify: 'read-write-plaintext-only' }), (line 600 of slate-react/src/components/content.js)

As well as importing IS_IOS, IS_SAFARI, (line 13 and 14)

Hope that helps someone.

dennisrcao on Sep 26, 2022

Back from out of internet range and can confirm that the -webkit-user-modify fix does work for us as well. Thank you everyone for chiming in with help. 🙏

beaugunderson on Sep 7, 2022

@beaugunderson

OMG! I can’t believe that all the issues in Chrome 105 described in my previous comment here were because of style WebkitUserModify: 'read-write-plaintext-only' on contentEditable container.

Thank you.

Code like this works for me: #editor-id:not(.disabled) { -webkit-user-modify: read-write; }

roman-korovets on Sep 6, 2022