Bullet/Editable: Use fastClick for clickHandler

[ethan-james]

Fix #1691

The Bullet component was using onClick to dispatch its setCursor action, which has a noticeable delay on iOS. Wrapping the click handler in fastClick solves the issue.

In Editable, the onTap handler was ignoring taps that would cause the keyboard to open, and falling back to the onFocus handler after a 300ms delay. It was necessary to intercept those taps and set the cursor with a manual offset to put the caret back at the end of the thought on iOS Safari. There was also some flakiness where selection.set wasn't always opening the keyboard, so now it calls contentRef.current.focus() explicitly.

[ethan-james]

The caret was getting positioned at the end of the thought somehow onFocus, so I wanted to preserve that behavior onTap.

[ethan-james]

I'm not quite sure why this is necessary, but it was having the following problem on iOS Safari:

1. Tap a thought - cursor moves, keyboard stays closed
2. Tap it again - keyboard opens
3. Close keyboard
4. Tap it again - keyboard does not open

[raineorshine]

Thanks, good catch.

I'll create a separate issue to get to the bottom of this.

[trevinhofmann]

Thank you, @ethan-james!

Switching to fastClick seems to have done the trick, when I test locally:

thoughts.mp4

[raineorshine]

Thanks for the submission! I can confirm that the timing is correct now.

The only problem I'm seeing is that the selection offset is not correct when tapping in the middle of a non-cursor thought in edit mode. This behavior relies on the default browser behavior to set the selection underneath the user's finger.

Steps to Reproduce

- Hello World
- x

1. Set the cursor on x.
2. Tap x to open the keyboard if it's not open already.
3. Tap in between Hello and World.

Current Behavior

a81cfd8

The caret is placed at the end of the thought, i.e. Hello World|

Expected Behavior

main

The caret should be placed in between Hello and World, i.e. Hello| World.

[ethan-james]

When I tested it on the main branch, I saw that onFocus would place the caret at the end of the thought, so that's the behavior that I tried to emulate. I'll see if instead I can come up with a reliable way to determine the selection offset from a touchend event.

[raineorshine]

Do you know why the onTap handler is ignoring attempts to open the keyboard. Is one of the e.preventDefaults being called?

My sense is that it would be more reliable to fix the root cause of the keyboard not appearing rather than trying to restore the selection and offset after the fact. But let me know what you find out!

[ethan-james]

Do you know why the onTap handler is ignoring attempts to open the keyboard. Is one of the e.preventDefaults being called?

My sense is that it would be more reliable to fix the root cause of the keyboard not appearing rather than trying to restore the selection and offset after the fact. But let me know what you find out!

It used to call onTap which would fall back to onFocus in this circumstance (cursor already on thought, keyboard closed). onFocus had a ~300ms delay so we're not using that anymore (by including e.preventDefault and manually managing the selection).

All of the advice on Google for eliminating click/focus delays is 10 years old and doesn't work, but I did just now put together a CodePen (https://codepen.io/ethan-james-the-sasster/pen/ByBYqrL) showing that the delay doesn't occur on simple contenteditable divs. So maybe there is hope for eliminating the delay at the source and going back to using onFocus, which I agree is a better solution.

Last thing to point out, though, is that on the iPad I'm using, the native focus behavior places the caret at the end of the editable text, and there doesn't seem to be a way to tap it into a different location. I've already emulated that behavior, although I agree that letting the browser control it natively is better.

[ethan-james]

Also, I wasn't able to find a way to get the offset from a touchend event. If we do decide to pursue manually setting the offset, I think we have to try one of the usual suspects:

1. Estimating the width of each character and dividing by the touch x/y position
2. Inserting a hidden element and measuring its size with different combinations of characters

[raineorshine]

All of the advice on Google for eliminating click/focus delays is 10 years old and doesn't work, but I did just now put together a CodePen (codepen.io/ethan-james-the-sasster/pen/ByBYqrL) showing that the delay doesn't occur on simple contenteditable divs. So maybe there is hope for eliminating the delay at the source and going back to using onFocus, which I agree is a better solution.

Yes, exactly. The delay is not inherent to contenteditables, but is being created through our own event handling. There is admittedly a lot of complexity with the selection handling, including automatically setting the selection when a thought re-renders, via useEditMode. However, theoretically we shouldn't need a lot of complex functionality for setting the caret when we are already in edit mode. The default browser behavior should set the caret under the user's finger on touchend.

Last thing to point out, though, is that on the iPad I'm using, the native focus behavior places the caret at the end of the editable text, and there doesn't seem to be a way to tap it into a different location. I've already emulated that behavior, although I agree that letting the browser control it natively is better.

Interesting. My last few iPhones have correctly set the caret in the middle of the thought in these cases. I haven't tested on iPad recently, but I would assume with the same version of iOS it would behave the same. What version of iOS are you running? Do you possibly have another device or way to reproduce the default caret behavior? It might be difficult to troubleshoot this otherwise.

Also, I wasn't able to find a way to get the offset from a touchend event. If we do decide to pursue manually setting the offset, I think we have to try one of the usual suspects:

1. Estimating the width of each character and dividing by the touch x/y position
2. Inserting a hidden element and measuring its size with different combinations of characters

Yes, that's what I was worried about. It's plausible, but strikes me as high effort + high risk. Plus, inserting a DOM element and measuring it may introduce a delay itself, negating the benefit of the fastClick.

[ethan-james]

Here's what I see on an iPhone running 18.1.1. You can see that I can tap to the end of the editable div, or to the beginning, or select all.

ScreenRecording_01-09-2025.09-39-04_1.MP4

[ethan-james]

I just tried it with longer text in the editable div, and I see that you can also tap to the end of any given word. 🤦

[raineorshine]

I just tried it with longer text in the editable div, and I see that you can also tap to the end of any given word. 🤦

Yes, that too! In that case, I really don't recommend trying to programmatically recreate the default caret offset behavior on tap.

[ethan-james]

I just tried it with longer text in the editable div, and I see that you can also tap to the end of any given word. 🤦

Yes, that too! In that case, I really don't recommend trying to programmatically recreate the default caret offset behavior on tap.

Yes, I would like to avoid it as well! I'm looking into why the focus delay exists, so hopefully that will bear fruit.

[raineorshine]

Thanks. Let me know if any of the existing selection logic needs clarification. I may not be able to explain all the details that have built up over time, but I'll do my best to elucidate anything that is particularly confusing.

[ethan-james]

I found out that react-dnd was using this option: { delayTouchStart: TIMEOUT_LONG_PRESS_THOUGHT } which was causing about a 300ms delay before focus. I removed it and I think drag & drop is still working OK, although there may be specific reasons why that delay was included in the first place.

There still may be about a 100ms delay between touch events & focus.

It looks a bit different from the CodePen

but there could be React or app-related overhead baked into that.

[raineorshine]

Good catch! Interesting that that changed the touchend timing. We want the long press and drag-and-drop timing to remain unchanged from the user's perspective, so hopefully this doesn't affect that.

[ethan-james]

Long press timing should be unaffected, and I tested drag-and-drop some more. Without any delayTouchStart, drag-and-drop works well but takes control immediately and doesn't allow drawing gestures on top of editable elements.

If I set delayTouchStart to 100ms, then everything seems to feel similar to how it was before. Gestures can be drawn, presumably the window for allowing them is smaller but I can't really tell from playing around with it.

There was always a 100ms delay (even with delayTouchStart set to 0) and I haven't been able to locate the cause of that. It seems remarkably consistent in its timing, so presumably it's intentional on some level. I tried to remove react-dnd entirely to see if the delay went away, and as best I could tell it did not. That was a messy process, so I'm not terribly confident in the result that I got. This delay also affects non-editable elements such as the hamburger menu. The 300ms delay that was plaguing the hamburger menu is also down to 100ms, but it is still affected. To be clear, hamburger menu is still using fastClick so there's currently no delay. I'm just talking about focus/click events.

So as things stand, I think that setting delayTouchStart: 100 is the way to go. In addition to the possible inevitability of that delay, it also restores behavior like drawing gestures on top of thoughts. I haven't committed that change yet, in case you have a different view.