Slate: 3-finger drag creates a delay where the state can get out of sync

Created on 7 May 2017 · 5Comments · Source: ianstormtaylor/slate

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

Bug

What's the current behavior?

After selecting text with the cursor, backspace will only delete the selection sometimes. Once it fails once, it appears to fail consistently. See the following gif which shows how the third selection does not get deleted correctly.

What's the expected behavior?

The selected text should be deleted.

This happens for me on http://slatejs.org/#/rich-text in Chrome, Firefox and Safari on my mac. I have a similar problem on draftjs.org, and so this might be related to this draftjs issue.

bug ♥ help ⚑ cross platform

Source

marekolszewski

Most helpful comment

@marekolszewski Are you using a trackpad with 3 finger drag? There is a 300ms delay before the selection updates. If so, you will have to wait 300ms for it to work.

echenley on 10 May 2017

👍2

All 5 comments

@marekolszewski Are you using a trackpad with 3 finger drag? There is a 300ms delay before the selection updates. If so, you will have to wait 300ms for it to work.

echenley on 10 May 2017

👍2

@echenley Yes, I am using 3 finger drag on a trackpad! Wow, that's an amazing guess 👍 I'm confirming that the issue goes away when I use click and drag. Where does the 300ms come from? Is that from MacOS or from within Slate?

marekolszewski on 19 May 2017

It's from OS X. The wait is to allow you to place 3 fingers down again immediately, so you can drag things long distances without running out of trackpad. I realized it myself while looking into this draft-js bug https://github.com/facebook/draft-js/issues/991. The gif looked familiar!

That said, the same issue applies here. It's not just 3 finger drag but the fact that the selection state isn't updated until mouseup (which happens 300ms later than expected when using 3 finger drag). You can replicate this with a mouse if you don't let go of the button before pasting.

Mac doesn't handle this particularly well at an operating system level (it queues up pastes without updating the UI and performs them all at once after mouseup). Windows seems to have the correct behavior, i.e. the paste happens immediately with the correct selection, even before mouseup.

echenley on 19 May 2017

Note: this doesn't happen with Prosemirror, which also uses contenteditable, so I'm not certain we can definitively label it an OSX issue. Draft does exhibit similar issues, though. Maybe a React thing.