300004 - Bidi: LTR characters typed at the right edge of RTL text appear to the left of that text

Status: RESOLVED WORKSFORME

(Core :: Layout: Text and Fonts, enhancement)

Description

[Uri Bernstein]

In a textarea which contains bidirectional text, use the right arrow key to move
to the right edge of an RTL phrase which is followed by LTR text.
Then, when you type LTR (or even neutral) characters, they appear to the left of
the RTL text (while the caret remains at the right edge of that text).

Moving the caret one character further to the right and typing RTL text, the RTL
text appears to the left of the existing RTL text (once again, the caret remains
at its place).

Testcase will follow soon.

Comment 1

[Uri Bernstein]

Attachment: testcase

Self-explaining testcase.

Comment 2

[Eyal Rozenberg]

Seeing this bug on WinXP. It may be a dupe though - with all these RTL caret
bugs, I just can't tell...

Comment 3

[Uri Bernstein]

Attachment: testcase #2

Here's another, more realistic, testcase (reversing LTR and RTL), which
demonstrates why this is a real, painful, problem, and not a theoretical issue.


Starting from the beginning (right) of the field, use the left-arrow to move to
the right of the "3". Now type the digit "4". To the complete surprise of the
unexpecting user, the "4" appears to the *left* of the "123", the result being
"4123".

The same happens when coming from the left (using right-arrow), and attempting
to add a digit to the left of the "1". The digit will be added to the right of
the "3" instead.

Comment 4

[Uri Bernstein]

People CC'ed on this bug are hereby encouraged to read (and comment upon) my
thoughts on the subject of bidi editing on the MozillaWiki:
http://wiki.mozilla.org/User:Uri/Bidi_editing, where I try to explain why this
bug is inherent to the current system, and outline an alternative approach which
might get this (and similar problems) fixed.

Comment 5

[Uri Bernstein]

The issue of the caret appearing in the wrong place after typing was resoved by the patch for bug 308023.

The other issue (typed character appearing not where the caret is) remains - however it seems to be the standard behaviour in both Windows and Mac, so I guess this makes this bug more of an RFE (implementing the system proposed on the wiki page).

I'm interested in other's opinions on this. Would fixing it be useful, or are people already so used to the current OS behaviours that they actually expect it to work this way?

Comment 6

[Eyal Rozenberg]

(In reply to comment #5)

> however it seems to be the standard behaviour in both Windows and Mac

Since when is visual caret movement default behavior on Windows?

Anyway, this behavior seems inconsistent with visual character movement. For me, as someone who wants logical caret movement, it's not very important... still, do fix it if you can.

Comment 7

[Uri Bernstein]

(In reply to comment #6)
> (In reply to comment #5)
> 
> > however it seems to be the standard behaviour in both Windows and Mac
> 
> Since when is visual caret movement default behavior on Windows?

I didn't say that, but you're right that the current behaviour is the only one that is consistent with logical caret movement. 

> For me, as someone who wants logical caret movement [...]

You can have it, starting from tomorrow's trunk nightly (containing the patch for bug 330175), by setting bidi.edit.caret_movement_style to 0.

Comment 8

[Eyal Rozenberg]

To summarize my view: the behavior should stay as-is for logical, and be fixed for visual.

Comment 10

[Uri Bernstein]

(In reply to comment #5)
> [...] [I]t seems to be the standard behaviour in both Windows and Mac, so I
> guess this makes this bug more of an RFE (implementing the system proposed on
> the wiki page).

Classifying as an RFE, then.

Comment 11

[(no longer active)]

Mass-assigning the new rtl keyword to RTL-related (see bug 349193).

Comment 12

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:jfkthame, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 13

[Jonathan Kew [:jfkthame]]

There have been some changes since this was originally filed, and the behavior on the testcases here seems reasonable to me (subject to the inherent ambiguities of bidi editing). As such, I'm going to close this as WFM.

In case there are remaining issues that we should consider further, please file a new bug with specific details and testcases to make the requirements clear.