328834 - Removing input using the backspace key should require the same number of keystrokes that were used for generating this input, regardless of input directionality.

Status: RESOLVED FIXED

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

Description

[pvoid]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Going backwards using the backspace key through a typed stream which consists of both Latin and Hebrew characters requires an additional keystroke whenever a switch in directionality occurs.

Reproducible: Always

Steps to Reproduce:
1. Type a Hebrew letter followed by a Latin one (or vice versa).
2. Hit backspace twice.
Actual Results:  
Only one of the letters deleted.

Expected Results:  
Both letters should be deleted.

Roots of this behavior can be traced through Uri's essay on Bidi editing http://wiki.mozilla.org/User:Uri/Bidi_editing . I, and I believe other touch typists that are used to backspace backwards for making corrections, find this discrepancy quite disruptive.

Comment 1

[Uri Bernstein]

I'll summarize what I wrote (in Hebrew) in http://www.mozilla.org.il/board/viewtopic.php?p=16582#16582 (where this discussion started):

* The current behavior is by design. The design can be found at http://www-306.ibm.com/software/globalization/topics/bidiui/multiline.jsp, under "Backspace and Delete".

* PVOID's experience is that this behavior is distracting and unexpected for experienced bidi typers. This is something that we should give much consideration to.

* However, I still believe that the current behavior is helpful to many users (e.g. unexperienced typers, like me) in most situations, and to most users in some situations.

Two possible solutions:

* Let the user decide if they want this behavior or not. Practically, in Firefox, this will have to be done using a hidden preference. Then we have to decide what would be the default, which I suggest should be the current behavior. Hidden prefs, however, have their drawbacks, such as low discoverability, and maintenance cost.

* Do something similar to what I proposed in the wiki page linked above: have a "visual mode" (switched on by moving the caret using the mouse or arrow keys) and a "logical mode" (switched on by typing or deleting). The current delete behavior will only be in effect in visual mode. I think this is the best solution, but it's more work than the other possibilities.

The other options are, of course, to kill this feature completely (which is easy, but IMO wrong), or to leave things as they are (i.e., WONTFIX).

Simon, I'm interested in what you have to say about this.

Comment 2

[Prognathous]

I went over the "Backspace and Delete" section in the aforementioned IBM document and still fail to see where this behavior is supposed to be beneficial for the user. Feel free to clue me in. In actual use I personally find it quite annoying.

I can think of two possible reasons why this behavior doesn’t work very well for most users, not only touch-typists:

1. Inconsistency with other Windows text fields (and probably those of other operating systems as well). In other words, if I press Backspace twice, the last two characters are always deleted - regardless of their BiDi level and the program I happen to be using.
2. Inconsistency with how physical objects "behave" in real life. If I place one object on a platform and then another object adjacent to it, removing them one after the other doesn’t require any "pseudo-removal" action in between.

I could probably think of better examples than that last one, but suffice to say, the current behavior simply feels wrong. What exactly is it set out to solve?

Prog.

Comment 3

[Matitiahu Allouche]

Hello, Prognathous, I will try to clue you in.
Delete and Backspace are destructive functions, so the user should know what he is going to erase before actually doing it. The location of the cursor is supposed to indicate the character which will be removed.  However, when the cursor is logically at a boundary between characters of different directions, the location of the character to remove is remote, on the display, from the location of the cursor. This could induce the user to think that he is going to remove a character different from the one which will actually be removed.
To avoid such a surprise, there is the intermediate step of relocating the cursor to be near the character to be removed.
Note that the reference design document (http://www-306.ibm.com/software/globalization/topics/bidiui/multiline.jsp) recommends "to provide a user option, by which users can choose if they prefer to have Backspace and Delete move the cursor without removing a character when the cursor is visually far from the cursor position or to have Backspace and Delete remove a character anyway."

Comment 4

[Simon Montagu :smontagu]

(In reply to comment #3)
> Note that the reference design document
> (http://www-306.ibm.com/software/globalization/topics/bidiui/multiline.jsp)
> recommends "to provide a user option, by which users can choose if they prefer
> to have Backspace and Delete move the cursor without removing a character when
> the cursor is visually far from the cursor position or to have Backspace and
> Delete remove a character anyway."

If my memory does not deceive me, this recommendation was not in the version of the document which I had before me when writing the original Mozilla implementation.

This is also the first of the possible solutions in comment 1, and I think it is the best of them. Since I am here suggesting a new pref, I should follow the advice at http://weblogs.mozillazine.org/ben/archives/009620.html :

"If you want to add an esoteric backroom workaround to an existing feature stop and think - is this so useful to the world at large that it requires a UI pref?"

I think the answer is that it is so useful to that subset of the world at large that types text in bidirectional languages that it should have a UI pref which is by default only visible in bidirectional locales (as is currently the case with "Switch page direction" in the View menu). Just as happened there, the UI could originally be developed in an extension.

Comment 5

[Simon Montagu :smontagu]

Attachment: Implement a user option

Comment 6

[Uri Bernstein]

Comment on attachment 213744 [details] [diff] [review]
Implement a user option

Looks good to me.

Comment 7

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'm not convinced. How will users discover and set this pref? Even if they do, how many such users are immune from the confusion described in comment #3?

Uri's visual/logical modes seem like a better solution to me. Wouldn't they negate the need for this patch?

Comment 8

[Simon Montagu :smontagu]

(In reply to comment #7)
> I'm not convinced. How will users discover and set this pref? 

The idea is to have a follow-up bug to create discoverable UI for this pref, as I mentioned at the end of comment 4.

>Even if they do,
> how many such users are immune from the confusion described in comment #3?

Most native Hebrew typers seem to think they are. See comment 2 and the discussion Uri linked to. Sample quotation:

ה-white paper הזה של IBM בנקודה הזאת הוא לא פחות מתמוה - מצד אחד מתעקש על פתרון בעיה שאינה שכיחה במיוחד ובכל מקרה פתירה גם בדרכים אחרות כמו למידת ההתנהגות והסתגלות או שימוש ב-undo במקרים בהם, שומו שמיים, אירעה הטעות המצערת ונמחק התו הלא נכון, ומצד שני לא מוטרד מכך שבמחיר הפתרון הזה משולמת שבירת סטנדרד דה-פקטו של הרגלי הקלדה ותפקידי מקשים. אני לא שוכנעתי.

"IBM's white paper on this point is somewhat inexplicable -- on the one hand it bends over backwards to solve a not very common problem which in any case is soluble by other means such as learning the behaviour and becoming accustomed to it, or using undo in cases where, like oh my gosh, the user makes a mistake and deletes the wrong character. On the other hand it is not worried by the fact that the solution pays the price of breaking a de facto standard of typing habits and keypress functions. I'm not convinced."

> Uri's visual/logical modes seem like a better solution to me. Wouldn't they
> negate the need for this patch?
 
From reading about it, my impression is that Uri's dual-mode solution would be even more confusing for users, but I am more than willing to experiment with a trial implementation of it (and to help producing one).

In general, I lean more towards de facto standards in UE than I did a few years ago.

Comment 9

[Simon Montagu :smontagu]

I should know by now to set encoding to UTF-8 in bugzilla before pasting in non-Latin1. The quotation in the last comment is:

ה-white paper הזה של IBM בנקודה הזאת הוא לא פחות מתמוה - מצד אחד מתעקש על פתרון בעיה שאינה שכיחה במיוחד ובכל מקרה פתירה גם בדרכים אחרות כמו למידת ההתנהגות והסתגלות או שימוש ב-undo במקרים בהם, שומו שמיים, אירעה הטעות המצערת ונמחק התו הלא נכון, ומצד שני לא מוטרד מכך שבמחיר הפתרון הזה משולמת שבירת סטנדרד דה-פקטו של הרגלי הקלדה ותפקידי מקשים. אני לא שוכנעתי.

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 213744 [details] [diff] [review]
Implement a user option

okay.

Comment 11

[Simon Montagu :smontagu]

Attachment 213744 [details] [diff] checked in.