[Discussion] By arrow key movement, the cursor should be able to reach the inline end.

Do you want to request a feature or report a bug?

feature Relate to https://github.com/ianstormtaylor/slate/pull/1582

What’s the current behavior?

If I am not wrong, the onSelect skip the inline end because the mouse click in some browsers cannot catch the inline end. But the logic of key input, which is decided by packages/slate slate core codebase, is consistent crossing browsers. We should normalize the selection when and only when the mouse click happens.

I think we should provide is{Something}VisiblyTheSame for on{Event}. These methods are designed to

1. If the computed slate variable is not significantly different from the existing range in the slate value, then do not normalize
2. if normalize, we would prefer the range closer to the existing range in slate value
3. otherwise, use the normalized range

Then we still have consistent behavior between browsers, and we can have the cursor at the end of inline to insert and delete.

[urugator]

In firefox the behavior depends on how the selection was obtained:

• mouse click: depends on which inline the user actually clicked (the cursor can end up in both)
• mouse selection: same as click - it depends where mouseUp was performed (this is a little bit weird because you may have a selection like aaa[bbb] and end up in “aaa”)
• arrow keys: depends on direction - the selection ends up in the node closer to previous selection: |<aaa><bbb> -> <aaa|><bbb> <aaa><bbb>| <- <aaa><|bbb>

I even tried IE11 just out of intereset:

• selection can be obtained in both (similary to firefox)
• but insertions are always in the next (similary to chrome)
• arrow movement always places selection to the next (opposite of chrome)

[urugator]

Hi, not sure if it helps somehow, but I tried to briefly test the default behavior of contenteditable on Chrome, what I found out:

• it doesn’t matter whether the inline is followed by some textual node or not, the behavior is always the same
• the selection is always in the same node as the character directly preceeding the selection (this is even indicated by the cursor having the same styling as the character before) - so actually, the selection is always in the “previous”, not in the “next” node…
• THE TWIST: even though the selection is always inside “the previous” inline, whenever user inserts (by typing/pasting) any content, the selection jumps right after the current node prior to inserting the content (this seems like bug to me)

In conclusion:

• selection is always in previous inline
• inserting content causes the selection to move outside prior to inserting content

Could we preventDefault all insertions and perform them manually?