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

Status: RESOLVED DUPLICATE of bug 427824

(Core :: DOM: Editor, defect)

Description

[Justin Lebar (not reading bugmail)]

Attachment: 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.

Comment 1

[Justin Lebar (not reading bugmail)]

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.

Comment 2

[Justin Lebar (not reading bugmail)]

For context, see comments 40 and 41 in bug 496275.

Comment 3

[(no longer active)]

I think the space after the تَ should be LTR.  CCing Johnathan and Simon to confirm this.

Comment 4

[Simon Montagu :smontagu]

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.

Comment 5

[Justin Lebar (not reading bugmail)]

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.

Comment 6

[Simon Montagu :smontagu]

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

Comment 7

[Simon Montagu :smontagu]

Like bug 427824, this also depends on the value of layout.word_select.eat_space_to_next_word.

Comment 8

[Justin Lebar (not reading bugmail)]

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.

Comment 9

[(no longer active)]

(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?