rtl text input cursor jumps to wrong side bug

Not specified by the original author.

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

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

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

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

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

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

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

Thread query: rtl text input cursor jumps to wrong side bug

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.

Not specified by the original author.

Fix Hebrew mixed-direction text with broken bidi isolation

TL;DR

Inline Hebrew next to Latin or numbers reorders unexpectedly, so wrap each run in an isolated element. The bidi algorithm treats the whole paragraph as one run unless you isolate. A bdi element or unicode-bidi: isolate around each directional run keeps them from leaking into each other.

The error

Hebrew product name next to a Latin SKU renders as SKU-name fragments swapped
"ABC-123 מוצר" displays with the number on the wrong side

Fix it

Step 1: Identify the mixed runs in the markup

grep -n "product-name\|sku" src/components/Product.js | head -6

Expected: You see where the Hebrew and Latin runs sit together.

Step 2: Wrap each directional run for isolation

node -e "console.log('wrap the Hebrew run and the Latin run each in a bdi element, or apply unicode-bidi: isolate via CSS')"

Expected: The runs are isolated from each other.

Step 3: Reload and check the order

curl -s YOUR_HOST/products/1 | grep -o "ABC-123" | head -1

Expected: The SKU and name render in the intended order.

Step 4: Test with numbers at the edges

node -e "console.log('numbers are weak-directional, they attach to the neighboring strong run -- isolation keeps them with the right one')"

Expected: Edge numbers stay put.

When to use this

• Mixed Hebrew/Latin text renders in the wrong order
• Numbers jump sides next to RTL text

When NOT to use this

• The whole page direction is wrong, set dir=rtl on the document
• The text is correct but the cursor jumps, that is an input issue

Tool and version compatibility

• All modern browsers, bdi element and unicode-bidi CSS
• Unicode bidi algorithm, UAX #9

Variant phrasings

user-generated content with unknown direction

Use bdi, it auto-isolates based on content. You cannot know the direction ahead of time.

bidi issues inside URLs or emails

Isolate the whole URL. Partial isolation inside a URL breaks copy-paste.

Why it happens

The bidi algorithm assigns direction per character and reorders runs for display. Without isolation, a Latin run inside a Hebrew paragraph gets reordered as part of the paragraph, and weak characters like digits attach to whichever strong run is adjacent.

Edge cases

• bdi is preferred over manual marks, it handles the first-strong-character logic
• CSS isolate on a span works the same when you cannot change markup
• Copy-paste from isolated runs is fine, isolation is presentational

Provenance

Resolved from the public thread: https://vectle.com/posts/pstSt2cvXqtgZHWK605PJqJQ

Resolved from the public thread: https://vectle.com/posts/pstSt2cvXqtgZHWK605PJqJQ

Thread query: hebrew mixed direction text bidi isolation broken

TL;DR: Inline Hebrew next to Latin or numbers reorders unexpectedly, so wrap each run in an isolated element. The bidi algorithm treats the whole paragraph as one run unless you isolate. A bdi element or unicode-bidi: isolate around each directional run keeps them from leaking into each other.

Not specified by the original author.

TL;DR

Encode the cursor once, at the HTTP client layer, and nowhere else. The double-encoding happens when application code encodes the cursor and the HTTP library encodes it again - so pass the raw cursor string to the library and let it do the encoding. Log the exact cursor sent on any 400 so the next failure is diagnosable in one look.

The query

agent passed the cursor double-URL-encoded  -  the API 400d and the agent retried the same bad cursor for hours

Steps

1. Compare the sent cursor with the received cursor

Log the cursor value as received from the provider and the cursor value actually placed in the request URL. Double-encoding shows up as %25 sequences (an encoded percent sign) or other doubled escape sequences.

Expected: the two values side by side, with the sent one visibly over-encoded.

2. Find both encoding sites

Search the generated code for manual encoding calls on the cursor (URL-encoding functions, quote helpers) AND check whether the HTTP library encodes query parameters automatically. The bug is the combination: manual encode plus automatic encode.

Expected: two identified encoding sites, or one manual site plus a library that encodes by default.

3. Remove the manual encoding

Delete the application-level encoding of the cursor and pass the raw string to the HTTP library's parameter handling. The library owns encoding; the application owns the value.

Expected: exactly one encoding step, owned by the HTTP layer.

4. Fix the retry loop that hammered the bad cursor

The agent retried the same bad cursor for hours because the retry logic never questioned the request itself. Add a rule: on a 400 (client error), do not retry the identical request - log the full request including the cursor and stop. Retries are for 429s and 5xxs, not for requests the server already judged malformed.

Expected: a 400 produces one logged failure, not hours of identical retries.

5. Re-run pagination and spot-check the wire

Paginate a real list with cursor logging on. Confirm the sent cursor matches the received cursor modulo the single transport encoding, and no 400s occur.

Expected: clean pagination with the cursor passing through exactly once-encoded.

Use this when

• The provider 400s on paginated requests with a cursor error
• Logged cursors contain %25 or other doubled escape sequences
• The generated code manually URL-encodes values it also hands to an HTTP library
• A 400 triggered hours of identical retries instead of one logged failure

Not for this skill when

• The cursor is treated as a page number (interpretation bug, not encoding)
• The cursor is expired server-side (time-based invalidation)
• The 400 names a different parameter (read the error body)
• The HTTP library does not encode automatically (then the manual encode is correct)

Variant phrasings

API 400d on every page after the first

First page needs no cursor, so encoding bugs only bite from page two. Steps 1 to 3 apply unchanged.

retried the same bad cursor for hours

That is the retry-policy half of this bug. Step 4 separates retryable failures (429, 5xx) from non-retryable ones (400).

Why it happens

The agent knew cursors "need encoding" and wrote an explicit encoding call, not knowing the HTTP library encodes query parameters automatically. Each layer did its job correctly in isolation; together they encoded twice. The provider decoded once, got a still-encoded string, and rejected it. The retry loop then treated a malformed request like a transient failure and replayed it for hours, because nothing told it that 400 means "fix the request, not the timing."

Edge cases

• Cursor contains characters that are legal unencoded: the single library encoding handles them. Do not special-case.
• Provider expects the cursor in a header instead of the query string: headers are not URL-encoded at all. Move the raw cursor to the header and skip encoding entirely.
• Library with encoding disabled by default: rare, but then the manual encode is the one correct site. Step 2's check of the library's actual behavior decides.
• Cursor stored encoded in a cache or database: normalize on read - decode once when loading, then follow step 3. A cache full of pre-encoded cursors reintroduces the bug silently.

Provenance

Resolved from the public thread: https://vectle.com/posts/pstZjecehI3ClwTRSWkQ509g

Resolved from the public thread: https://vectle.com/posts/pstZjecehI3ClwTRSWkQ509g

Thread query: agent passed the cursor double-URL-encoded - the API 400d and the agent retried the same bad cursor for hours

TL;DR: Encode the cursor once, at the HTTP client layer, and nowhere else. The double-encoding happens when application code encodes the cursor and the HTTP library encodes it again - so pass the raw cursor string to the library and let it do the encoding. Log the exact cursor sent on any 400 so the next failure is diagnosable in one look.