# Fix RTL text input cursor jumping to the wrong side

## TL;DR

The cursor jumps because mixed-direction text confuses the caret, so isolate the input with dir=auto or unicode-bidi. Short inputs with mixed Hebrew and Latin text are the classic trigger. Setting the input direction explicitly stops the caret from teleporting.

## The error

```text
RTL input: typing a Latin word inside Hebrew text moves the cursor to the wrong end
caret jumps on every keystroke in mixed-direction input
```

## Fix it

### Step 1: Reproduce with a mixed-direction value

```bash
node -e "console.log('type Hebrew, then a Latin word, then Hebrew again -- watch the caret')"
```

Expected: You see the caret jump.

### Step 2: Set dir=auto on the input

```bash
grep -n "input" src/components/Search.js | head -3
```

Expected: You find the text inputs to fix, then add dir=auto so direction follows content.

### Step 3: Isolate the value rendering if you echo it

```bash
node -e "console.log('wrap echoed values in a bdi element or apply unicode-bidi: isolate')"
```

Expected: Echoed text no longer disturbs surrounding layout.

### Step 4: Retype the mixed string and confirm the caret stays put

```bash
node -e "console.log('same repro as step 1, caret now tracks typing')"
```

Expected: The cursor behaves.

## When to use this

- Caret jumps in RTL or mixed-direction text inputs
- Typing Latin inside Hebrew or Arabic text misbehaves

## When NOT to use this

- The text displays in the wrong order, that is a bidi isolation issue in display
- The input shows the wrong language entirely, check the value binding

## Tool and version compatibility

- All browsers, input and textarea elements
- dir=auto supported everywhere modern

## Variant phrasings

### jump only at the boundary between scripts

That is the bidi algorithm reordering. Isolation at the boundary fixes it.

### contenteditable instead of input

Same fix, but apply it per block inside the editable region, not just the root.

## Why it happens

The Unicode bidi algorithm reorders mixed-direction text for display, and the caret position is computed in that reordered space. Without explicit direction, each keystroke can change the paragraph direction, and the caret maps to a surprising spot.

## Edge cases

- dir=auto uses the first strong character, leading digits keep LTR until Hebrew appears
- Password fields mask the issue, test with visible text
- IME composition in CJK plus RTL needs testing on real devices, emulators differ

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_48audeq9ysa-JrzF7Fkhgw