Closed
Bug 300004
Opened 20 years ago
Closed 3 years ago
Bidi: LTR characters typed at the right edge of RTL text appear to the left of that text
Categories
(Core :: Layout: Text and Fonts, enhancement)
Core
Layout: Text and Fonts
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: uriber, Unassigned)
References
Details
(Keywords: rtl)
Attachments
(2 files)
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.
Reporter | ||
Comment 1•20 years ago
|
||
Self-explaining testcase.
Comment 2•20 years ago
|
||
Seeing this bug on WinXP. It may be a dupe though - with all these RTL caret
bugs, I just can't tell...
OS: MacOS X → All
Hardware: Macintosh → All
Reporter | ||
Comment 3•19 years ago
|
||
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.
Reporter | ||
Comment 4•19 years ago
|
||
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.
Reporter | ||
Comment 5•19 years ago
|
||
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•19 years ago
|
||
(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.
Reporter | ||
Comment 7•19 years ago
|
||
(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•19 years ago
|
||
To summarize my view: the behavior should stay as-is for logical, and be fixed for visual.
Reporter | ||
Comment 10•17 years ago
|
||
(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.
Severity: normal → enhancement
Comment 11•17 years ago
|
||
Mass-assigning the new rtl keyword to RTL-related (see bug 349193).
Keywords: rtl
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
Updated•14 years ago
|
Assignee: mozilla → nobody
Updated•10 years ago
|
Assignee: nobody → tclancy
Comment 12•3 years ago
|
||
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.
Assignee: ted.clancy → nobody
Flags: needinfo?(jfkthame)
Comment 13•3 years ago
|
||
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.
Status: NEW → RESOLVED
Closed: 3 years ago
Flags: needinfo?(jfkthame)
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•