Closed Bug 167288 Opened 22 years ago Closed 4 years ago

Caret movement should match platform convention (Logical for Win32 and QT, Visual for GTK and Mac OS X)

Categories

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

defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1638240

People

(Reporter: ilya.konstantinov+future, Unassigned)

References

(Blocks 1 open bug)

Details

The cursor in Bidi input fields, both single line and multi line, seems to be
positioned and moved visually. e.g.:

In a direction:left input field:
1. Enter "SHALOM hello" (SHALOM being a Hebrew word).
2. Press the BACK key repeatedly.
Result: We're moving through the word SHALOM visually, SHIN first, then LAMED etc.

Same happens in direction:right fields, just this time the movement thru "hello"
is visual ("h" first, then "e"...).

This doesn't make any sense for bidi editing.

On 2002-09-05-22.
This behaviour is by design. I know that many people are used to logical cursor
movement from other applications, but we consider it more important to maintain
a consistent meaning for right arrow moving right and left arrow moving left.
WONTFIX.
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
http://bugzilla.abisource.com/show_bug.cgi?id=2658 makes an interesting
counterpoint to this bug report.
Your point seems correct too, and the Abiword bug proves there's user demand for
your way, but don't we also see it a bit problematic behaving differently from
other desktop software? Windows has logical cursor everywhere (including
visual-centric word-processor Word), Qt has logical cursor, GTK has visual
cursor. How do Macs work?
Blocks: BidiCaret
Visual cursor movement is very annoying and counter-intuitive AFAIC, especially
when you're used to working with a logical cursor. This _must_ be a pref, and
the default should be changed to logical, or to the default of the platform
(logical for Win,Qt; visual for GTK, etc).

I am not sure whether the fact that I have editbugs means I also have the right
to countermand Simon's WONTFIX, so I'll do it tentatively and if you (Simon)
feels it's out of line for me to do so than accept my apology. 
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
Changing the summary to a more specific one. Hardware & OS -> All.

I agree that this should be a pref. Personally, I like Visual caret movement,
even in Windows, but I can see why others don't want it, especially when Mozilla
itself uses *Logical* text selection (see Bug 195909).

Prog.
OS: Linux → All
Hardware: PC → All
Summary: Cursor moves visually → Caret movement should match platform convention (Logical for Win32 and QT, Visual for GTK and Mac OS X)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Blocks: 330175
(In reply to comment #5)
> Changing the summary to a more specific one. Hardware & OS -> All.
> 
> I agree that this should be a pref. Personally, I like Visual caret movement,
> even in Windows, but I can see why others don't want it, especially when Mozilla
> itself uses *Logical* text selection (see Bug 195909).
> 
> Prog.

I prefer logical caret movement, even under GTK, so let's make it a pref, and if possible not only in about:config but also in Edit -> Preferences. Pretty please? (and BTW, what about apps compiled with GTK2 but running under a KDE winmanager, or Qt apps running under Gnome?)
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: zach → layout.fonts-and-text
I should have thought of this long ago: now that we have the bidi.edit.caret_movement_style pref, isn't this trivial to fix?

I am assuming that the correct platform defaults are 0 for Windows, 1 for GTK and 2 for OSX, is this correct?
For Windows it's surely correct. :)
(In reply to comment #8)
> I should have thought of this long ago: now that we have the
> bidi.edit.caret_movement_style pref, isn't this trivial to fix?
> 

It's only trivial to "fix" if you actually consider it "broken" :-)

I'm pretty sure (although I can't find evidence) that we discussed this at the time, and I mentioned that it's now easy to fix, but that I won't do so myself because I believed that "logical caret movement" is inherently broken. I expected someone to go ahead and do this anyway (and was pretty happy that nobody did).
I also had the theory that people don't like visual movement just because the implementation had so many bugs, and I wanted to give the community an opportunity to use less-broken visual movement, and fall in love with it. Whether that happened is questionable.
The fact that I spent so much time fixing those visual-movement bugs also made me somewhat emotionally involved, I guess.

Anyway, I don't feel as strongly about this now as I did then (but I still won't supply the patch myself :-).


> I am assuming that the correct platform defaults are 0 for Windows, 1 for GTK
> and 2 for OSX, is this correct?

Correct for Windows and OS X, I'm not sure about GTK, but probably correct there too.
Hm. Does the GTK vs. Qt distinction mean "compiled with GTK" vs. "compiled with Qt" or "running under Gnome" vs. "running under KDE"? I suppose the former would be easier to implement but rather pointless if the intent is to behave the same way as the other apps typical of the current desktop. OTOH the latter might mean loss of a pref setting if a given user, having set the pref, switches back and forth between a Gnome desktop and a KDE desktop with the same profile (unless of course he sets the value explicitly in user.js rather than "only" in about:config).
Assignee: mozilla → nobody
(In reply to Simon Montagu :smontagu from comment #8)
> I should have thought of this long ago: now that we have the
> bidi.edit.caret_movement_style pref, isn't this trivial to fix?
> 
This pref doesn't seem to work any longer. I can only have the "hybrid" option (i.e. visual caret movement, logical selection) work. Values other than '2' have no effect. I am using Firefox 39.0.
Status: NEW → RESOLVED
Closed: 22 years ago4 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.