[Bug]: Incorrect selection and cursor behavior for RTL text in IText

[Nasser-sw]

CheckList

• I agree to follow this project's Code of Conduct
• I have read and followed the Contributing Guide
• I have read and followed the Issue Tracker Guide
• I have searched and referenced existing issues and discussions
• I am filing a BUG report.
• I have managed to reproduce the bug after upgrading to the latest version
• I have created an accurate and minimal reproduction

Version

6.6.4

In What environments are you experiencing the problem?

No response

Node Version (if applicable)

None

Link To Reproduction

https://codesandbox.io/p/devbox/fabric-nextjs-sandbox-forked-987kpy?workspaceId=ws_KPJkdGmaFKAMNymeZsxKvE

Steps To Reproduce

1- Initialize a Fabric.js canvas.

2- Create an IText object with an Arabic string, for example: 'هذه تجربة'.

3- Do not specify the direction property, allowing it to default to 'ltr'.

4- Add the text object to the canvas.

5- Using the mouse, attempt to click on the first word as it appears visually (the word هذه on the far right).

6- Attempt to click and drag to select the text from right to left.

7- Try to change a word it will change the opposite.

Expected Behavior

Intuitive Selection: The selection highlight should follow the mouse's path accurately, expanding from right to left as the user drags.

WYSIWYG Editing: Typing and deleting characters should happen at the cursor's visual position, providing a predictable "What You See Is What You Get" experience.

Actual Behavior

Reversed Selection: Dragging the mouse from right to left creates a selection highlight that expands in the opposite direction (from left to right).

Incorrect Editing: Typing or deleting characters affects the opposite end of the text from where the cursor appears visually. The editing logic follows the LTR model, which is disconnected from the visual RTL rendering.

Error Message & Stack Trace

[Nasser-sw]

There's a fundamental issue with hit-testing and text selection for bidirectional (BiDi) strings when an RTL script (like Arabic) is rendered within a container with its base direction set to LTR.

The core of the problem is a desynchronization between the logical order of characters in memory and their final visual order on the canvas after the Unicode Bidirectional Algorithm (UBA) has been applied by the rendering engine.

Technical Breakdown When handling the string "هذه تجربة" in an LTR context:

Visual Rendering: The browser or rendering engine correctly applies the UBA, visually rendering the string from right to left as intended for Arabic. The word هذه appears on the right, and تجربة appears on the left.

Logical Calculation: The library's internal logic for calculating character bounding boxes, cursor placement, and word selection appears to be operating solely on the string's logical (in-memory) LTR order. As shown in the provided character bounds data, the left coordinate increases sequentially from the first character in the string (ه) to the last (ة).

The Conflict: This creates a conflict. When a user double-clicks on the visually-rendered word هذه on the right side of the canvas, their click targets a high X-coordinate. The library's LTR-based hit-testing logic incorrectly maps this high X-coordinate to the characters at the end of the logical string, which corresponds to the word تجربة. Consequently, the selection is inverted from the user's perspective. The system is selecting based on the logical data model, which is completely misaligned with the visual presentation.

[asturur]

The idea was to flip the X coordinate in respect of the bounding box, i think this is a known issue that should be already opened.

[Nasser-sw]

Tried that didn't work unfortunately.

Using HTML textarea as overlay edit. kinda works similar to konva

[asturur]

RTL needs to be supported. Is a matter of decency but the current state of text code is sub optimal and is not easy to slot in.

[Nasser-sw]

https://jsfiddle.net/nwg867u3/2/

This worked fine for me.