Slate: Enter deletes paragraph and replaces with new one in iOS Safari

[ericedem]

Do you want to request a _feature_ or report a _bug_?

Bug

What's the current behavior?

Hitting Enter in iOS Safari deletes the current paragraph and replaces it with an empty one, instead of starting a new paragraph.

Try any of the examples: https://www.slatejs.org/#/rich-text

Slate version: 0.40.2
Can reproduce on a real iPhone 7 v11.4.1
And in simulator iPhone X (pictured)

What's the expected behavior?

It should create a new paragraph.

Happy to contribute a fix if someone can point me in the right direction.

[janjiss]

Not sure if this is helpful, but after some investigation, I've found that when you remove !IS_IOS check from the following line https://github.com/ianstormtaylor/slate/blob/master/packages/slate-react/src/plugins/after.js#L464, it works as expected.

[dmitrizzle]

Does this still happen in slate 0.39 for you?

[ericedem]

I upgraded from 0.36.2 where it was working. It is broken in 0.37.7.

I ran a git bisect and it appears that the code broke in this commit, though I don't see anything directly related to iOS behavior: https://github.com/ianstormtaylor/slate/commit/877dea16bf11271bf3232ccfb20cc1f0147834a4

[dmitrizzle]

@zhujinxuan any ideas on what may have gone wrong here? I really am clueless.

[zhujinxuan]

@dmitrizzle No idea. I plan to work on desktop IMEs, but I have no experience about mobile part.

[ericedem]

@janjiss It looks like the !IS_IOS checks still need to be in there due to autocomplete issues on iOS. Described in #1471 and fixed in #1475.

Playing around with this a little bit more in the rich-text example, this bug seems a little more nuanced:

• Hitting 'Enter' in unmarked text deletes backward until hitting a mark.
• Hitting 'Enter' in marked text deletes backward until hitting unmarked text.
• Hitting 'Enter' exactly at the boundary of a mark and unmarked text, the line will be split.

[ericedem]

I did some debugging in the content editable component, and here are the events we are getting:

• 'onKeyDown' is fired, which is ignored due to the IS_IOS checks.
• 'onBeforeInput' is fired, with data "↵", and there is a return character added to the doc.
• 'onInput' is fired, which tries to insert a line break. Things get dicey here because for some reason the selection has been extended to the beginning of the current text node, and deleteAtRange() is called on the current selection.

I'm not super familiar with the guts here, but it seems like the problem has to do with the selection being incorrectly updated. I did see some places in content where selection has special handling, but not familiar with all the details yet.

[ericedem]

It looks like the change in 877dea1 that broke things was putting the event handlers in a handlers object, and not attaching them directly to the <Content> component. I'm still scratching my head a little bit as to why this is the case, since the handlers are arrow functions and bound correctly to the instance, seems like it should work to me. In any case, this change seems to fix the issues in both this bug and #2129:

--- a/packages/slate-react/src/components/content.js
+++ b/packages/slate-react/src/components/content.js
@@ -75,7 +75,7 @@ class Content extends React.Component {
    */

   handlers = EVENT_HANDLERS.reduce((obj, handler) => {
-    obj[handler] = event => this.onEvent(handler, event)
+    this[handler] = obj[handler] = event => this.onEvent(handler, event)
     return obj
   }, {})

[zhujinxuan]

@ericedem Hi, the handlers is put into the Content in https://github.com/ianstormtaylor/slate/commit/877dea16bf11271bf3232ccfb20cc1f0147834a4#diff-021b2a72cf52cd5e8214d0a035b3ebc9R78

[ericedem]

@zhujinxuan Yea, what I'm saying is that in that commit they are no longer added to the instance of <Content> anymore, only to an instance variable Content#handlers.

I just found out where the problem is, there are a couple of addEventListener calls that are now calling undefined methods because handlers only exist on the handlers object. Fix incoming.