Closed Bug 551877 Opened 10 years ago Closed 10 years ago

Contenteditable thinks that a space to the right of a RTL character belongs to that character

Categories

(Core :: DOM: Editor, defect)

defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 427824

People

(Reporter: justin.lebar+bug, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: rtl)

Attachments

(1 file)

Attached file Testcase
STR:
* In about:config, change bidi.edit.caret_movement_style to 0. (This corresponds to moving logically, rather than visually, in textboxes.  See http://kb.mozillazine.org/Bidi.edit.caret_movement_style)
* Load attached page
* Click to the left of the 'a'.
* Press <right> twice, so the cursor is just to the right of the تَ.
* Press <ctrl>+<right>

Expected results:
* Cursor is immediately to the right of the تَ.

Actual results:
* Cursor is to the right of the space to the right of the تَ.

It appears that this happens because the space to the right of the تَ picks up the RTL-ness of that character.
Note that the same thing happens if you don't modify the about:config setting.  But that might be the correct behavior in that case.
For context, see comments 40 and 41 in bug 496275.
I think the space after the تَ should be LTR.  CCing Johnathan and Simon to confirm this.
Keywords: rtl
Yes, the space should be LTR (a neutral character between two characters of different directionality has the base direction of the paragraph, which is LTR in this case).

That said, I can't reproduce the bug on either Mac or Linux trunk: after pressing <ctrl><right> the caret is logically immediately after the تَ. Where it is displayed is also affected by which keyboard is active: with an LTR keyboard it is displayed to the right of the تَ, but with an RTL keyboard it is displayed to the left. In either case this corresponds to where the next character typed will appear.
Looks like I carelessly messed up my STR:

  * Press <right> twice, so the cursor is just to the right of the تَ.

should have been

  * Press <right> twice, so the cursor is just to the *left* of the تَ.

I can reproduce on Windows XP and Linux trunk.
I can reproduce on Windows. On Mac I can reproduce if I copy the text to an input field (e.g. the search box), but still not in contenteditable.

This may be a dupe of bug 427824
Like bug 427824, this also depends on the value of layout.word_select.eat_space_to_next_word.
Depends on: 427824
This looks like it's either the same issue as bug 427824 or one very similar.  I'll mark as a dupe and comment in that bug that they should also test any fix against the testcase here.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 427824
(In reply to comment #4)
> That said, I can't reproduce the bug on either Mac or Linux trunk: after
> pressing <ctrl><right> the caret is logically immediately after the تَ. Where
> it is displayed is also affected by which keyboard is active: with an LTR
> keyboard it is displayed to the right of the تَ, but with an RTL keyboard it is
> displayed to the left. In either case this corresponds to where the next
> character typed will appear.

I can reproduce this easily on Mac.  The caret behaves like Windows and Linux (it jumps after the following space, where as it should jump before the following space, right next to the تَ.

(In reply to comment #6)
> I can reproduce on Windows. On Mac I can reproduce if I copy the text to an
> input field (e.g. the search box), but still not in contenteditable.

Maybe it has something to do with comment 7?
You need to log in before you can comment on or make changes to this bug.