209430 - Ctrl+Delete and Ctrl+BackSpace delete words in the wrong direction

Status: RESOLVED FIXED

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

Description

[Prognathous]

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.3) Gecko/20030314
Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.3) Gecko/20030314

In right-to-left forms, pressing Accel+Delete deletes backwards and
Accel+BackSpace deletes forwards - it should be the opposite.

Reproducible: Always

Steps to Reproduce:
1. Open http://oren.gomen.org/mozilla/textareas.html
2. Place the caret between the two words
3. Press Accel+Delete (Ctrl+Delete in Windows)
Actual Results:  
The first word is deleted (backward delete)

Expected Results:  
The second word should be deleted (forward delete)

Repeat test with Accel+BackSpace -> second word is deleted instead of the first one.

Tested with Mozilla 1.4rc1, 1.2.1 and Firebird 0.6 (WinXP Pro) and Mozilla 1.3
(BeOS)

Prog.

Comment 1

[Simon Montagu :smontagu]

Confirming. 

Comment 2

[Uri Dor]

prognathous, please add the words "ctrl" and "word" to the summary, so this bug
will be easier to query for.

Comment 3

[Prognathous]

Since this issue is more likely to be noticed by Windows and *nix users, I just
changed the term Accel in the summary to Ctrl. It is not likely that MacOS and
BeOS users will search for such a bug anyway, as word-deletion is not a standard
behavior under these systems, and since there certainly isn't any standard
modifier key for it.

Prog.

Comment 4

[Simon Montagu :smontagu]

Attachment: Patch v.0

Suggested patch, not yet tested.

Comment 5

[Simon Montagu :smontagu]

Attachment: Better patch

This works better.

Comment 6

[Daniel Glazman (:glazou) (not active in Mozilla any more)]

Comment on attachment 138742 [details] [diff] [review]
Better patch

yes!
r=[e-mail]

Comment 7

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Comment on attachment 138742 [details] [diff] [review]
Better patch

sr=dbaron.  I certainly wouldn't object if you went with the shorter but
probably slightly more cryptic

selCont->WordMove((caretBidiLevel & 1) == 0, PR_TRUE);

and

selCont->WordMove((caretBidiLevel & 1) != 0, PR_TRUE);

But it's certainly OK with me if you don't like that. :-)

Comment 8

[Prognathous]

The bug is still not fixed in one specific (and rather rare) scenario:
A. Input language has just been switched to a language with opposite direction
than the current textarea (e.g. English input in an RTL textarea)
-and-
B. The users hasn't moved the caret between the language switch and the deletion.

Steps to reproduce:
1. Make sure that the input language is Hebrew.
2. In the first textarea (RTL), put the caret in the begining of the second word.
3. Switch the input language to English
4. Press Ctrl+Delete

Actual results:
The first word is deleted.

Expected results:
The second word should be deleted.

This behavior primarily effects the first word deletion after a language switch,
most subsequent deletions are correct, except when linebreaks are reached.

Tested with 1.6/20040111 patched with this fix.

Prog.

Comment 9

[Simon Montagu :smontagu]

I think the fix to bug 162242 needs some refinement to eliminate that problem.