151999 - Text selection does not work properly in RTL multiline textareas

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect)

Description

[Eyal Rozenberg]

This isn't some new bug, but rather something that's been bothering me
for...ever. Whenever I'm composing a message and want to select a few of lines
what happens is this: if I press the mouse key, and go down vertically a few
lines then nothing at all is selected; if I press Shift and start moving (or
left), then at most one line is selected at any time and when I go over to the
next (or previous) line the selection is reset to zero.

There are even weirder phenomena with RTL text (I use Hebrew) where lines get
skipped in selection, etc.

This bug is probably a duplicate of some other bug entry but I couldn't find it
so I entered it

Comment 1

[Jean-Francois Ducarroz]

reassign to editor

Comment 2

[kinmoz]

--> mjudge (selection/caret navigation)

Comment 3

[Henrik Lynggaard Hansen]

Hi

This bug has not been touched in more than a year, so I'm trying to figure out
if it is still relevant.

Could you please try and reproduce this behaviour with a more recent build like
1.4 or later ?

Comment 4

[Eyal Rozenberg]

Bug remains in effect, at least for RTL text (I use Hebrew) - there have been no
changes over the past year in this respect.

Comment 5

[Prognathous]

WFM on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
I don't see any such problems with either Navigator, Composer nor with Mail&News.

Eyal, can you still reproduce this? if so, please add a detailed description of
the required steps.

Prog.

Comment 6

[Eyal Rozenberg]

Not only can I reproduce this - it _always_ happens. That is, whenever you enter
more than 2 lines of Hebrew text in a multiline text box, press the select
button and start moving around with the cursor using the arrow keys (at random
intevals depress and repress the shift key) the problems start. For example,
with the following 4 lines of text:

שלום לך השבת, שלום לך השבת,
שלום לך השבת, שלום לך השבת,
שלום לך השבת, שלום לך השבת,
שלום לך השבת, שלום לך השבת,

entered in this very form (Bugzilla bug processing form) - sometimes I select
the first two lines, continue moving the cursor down by one line and somehow the
selection now encompasses all of the text; and sometimes my when nothing is
selected and the cursor is at the left of the leftmost ת at the bottom line, and
I press shift and move the cursor up, the first (not the third) line is selected.

And the problem is even worse if I change the directionality of this form to
RTL, and have some selection with shift pressed, and I move the cursor one line
up, the scrollbar scrolls me all the way to the top and selects everything up to
there.

This is with build 2003-12-03-08. Same thing in Firebird, of course.

Comment 7

[Prognathous]

Attachment: Testcase #1

Eyal, maybe I'm being a bit dense here, but I still can't see the problems you
describe with text selection.

Please provide the exact steps needed to reproduce these problems, based on the
attached testcase. Try to be very specific as to where the caret should be
placed initially, and what order of keys should then be pressed. A similar case
that you might find to be a useful read is Bug 207186.

Thanks,

Prog.

Comment 8

[Eyal Rozenberg]

Use the lower box. Begin by having no selection and the cursor between the shin
and the bet on the left part of the second line. Click on the leftmost area of
the bottom line (near the margin). Press shift+up. The entire lower line will be
selected. Now click somewhere in the middle of the bottom line. Press home.
Press shift+up. Now all of the third line is selected, except for one character.

That is problem no. 1

Use the lower box. Click to the right of the rightmost shin in the third line.
Press shift+home. Nothing is selected but cursor moves to the leftmost part
(near the margin) of the fourth line. 

That is problem no. 2

Use the upper textbox. Click left of the leftmost character on the fourth line
(the space after the tav character). Press shift+up. All of the text is selected.

That is problem no. 3

How's that?

PS - again, I am using build 2003-12-03-08 but it's been this way for many
months now. Also, I haven't done anything weird to my OS (WinXP) to cause it to
behave differently.

Comment 9

[Prognathous]

Ok, Eyal, thanks for the detailed instructions.

I've managed to reproduce each case, but I don't think either of those is a bug.
This behavior is almost identical to IE6 - which is actually very surprising,
considering the major problems that Mozilla has with caret movement.

Some of these issues may look as a bug, but actually, when you're dealing with
Logical selection (vs. Visual selection) and with RTL text in an LTR textarea,
you're dealing with something that's highly unintuitive for most users, even
when it does comply with the intended design.

This bug should be marked as INVALID, but I'll wait for smontagu to share his
view first.

Prog.

Comment 10

[Eyal Rozenberg]

Prognatheus, I must disagree. The behavior is not at all like IE6 (I used
6.0.2800 to check).

First of all, the text is not even layed out the same way in IE6 (and I'm not
even sure their way is worse). And the behavior is _totally_ different. It is
not even _remotely_similiar_.

In problem no. 1: IE6 makes a different selection then mozilla in the first
selection described; the use of 'home' moves you to the right end of the last
line rather than the left end, like in Mozilla, and the second selection is
again different.

In problem no. 2: clicking on the rightmost part of the third line (which is now
no longer a shin but rather the comma), and pressing shift+home causes the
entire third line to be selected.

In problem no. 3: when pressing shift+up, the fourth line plus the leftmost
character of the third line are selected

Besides, it's not as though Mozilla is sticking to MSIE behavior - when it
should, like when laying out '-' characters between a hebrew letter and a number
as a hyphen, like IE does - Mozilla developers have chosen to adhere to other
standards.

The fact remains that the selection behavior is erratic, does not seem
consistent to the average user and hampers the writing flow. In fact, it is not
just selection itself but rather a combination of problems with both cursor
movement and selection.

Comment 11

[Eyal Rozenberg]

You know, come to think of it, especially after being able to reproduce so many
annoying facets of this bug, I think it has earned a severity of 'major' rather
than 'normal'.

Comment 12

[Eyal Rozenberg]

Sorry for spamming, but maybe a name change is also in order...

Comment 13

[Prognathous]

> Prognathous, I must disagree. The behavior is not at all like IE6 (I used
> 6.0.2800 to check).

I have the same version of IE and I find it text selection to be quite similar
to Mozilla - logically. Text layout is different, but this should be another
bug, if at all.

> In problem no. 1: IE6 makes a different selection then mozilla in the first
> selection described; 

IE selects both of the lower lines, while Mozilla does the right thing and only
selects the lowest one.

What would you consider to be the expected behavior?

> the use of 'home' moves you to the right end of the last
> line rather than the left end, like in Mozilla

That's caret movement - bug 207186

> and the second selection is
> again different.

Both browsers select the third line. True, Mozilla doesn't select the first
character, but this is expected considering that the home location of the fourth
line is right below the second character of the third line. -> Not a bug

> In problem no. 2: clicking on the rightmost part of the third line (which is now
> no longer a shin but rather the comma), and pressing shift+home causes the
> entire third line to be selected.

Both browsers do perform the right selection considering their slightly
different text layout. Remember this is Logical, not Visual selection. Pressing
Shift+Home should select everything in the same line, up to *Logical* beginning
(which in this context, is not necessarily the rightmost character).

In IE, putting the caret to the right of the rightmost comma means that it is at
the Logical *end* of the line. Shift+End should (and does) select the whole line.

In Mozilla, the rightmost character is the rightmost Shin, which is also the
Logical *beginning* of the line. Now, since the caret is already at the home
location, pressing Shift+End should not (and does not) select anything. The fact
that the caret moves to the next line is again, part of bug 207186.

In short, this too is not a bug either.

> In problem no. 3: when pressing shift+up, the fourth line plus the leftmost
> character of the third line are selected

This is the expected behavior, and it works exactly the same in both browsers.
The Logical selection between the last location in the fourth line, and the last
location in the third line does and should include all the characters in
between. -> Not a bug.

What would you consider to be the expected behavior?

> Besides, it's not as though Mozilla is sticking to MSIE behavior...

Mozilla and IE share most of the same logic when it comes to BiDi handling. The
differences are few, and in this context, both browsers behaved as expected.

Eyal, sticking to Bugzilla format [Steps to reproduce, Actuall results AND
Expected results] would have made this discussion much more concise and to the
point. Please use it when reporting future bugs.

Thanks you,

Prog.

Comment 14

[Prognathous]

For anyone who reads Hebrew and would like to continue this discussion without
spamming Bugzilla, please join the following thread:

http://mozilla.org.il/board/viewtopic.php?p=2573#2573

Sorry for the typos in my previous comment,

Prog.

Comment 15

[Eyal Rozenberg]

I want to clarify something which may not have been well enough understood by my
comment #10 : the behavior I'm describing in comment #10 is the behavior of
Microsoft Internet Explorer with this text, not that of Mozilla. In comment #8 I
describe Mozilla's behavior.

Comment 16

[Prognathous]

Ok, I finally managed to reproduce this bug. The caret should be at the end of
the line and *after the space*, not just after the last tav character.

-Steps to Reproduce-
1. Open the attached testcase (#1)
2. In the first textarea (RTL), put the caret somewhere on the last line.
3. Press End. The caret should move to the end of the line, after the space.
4. Press Shift+Up.

-Actual Results-
The entire text is selected (a screenshot is coming).

-Expected Results-
Only the last line should be selected.

Note that this problem doesn't happen in the LTR textarea, which behaves very
similarly to IE6 (in terms of text selection).

-Workaround-
To choose the selection point, click the mouse after the last tav character,
rather than after the last space.

Confirming bug as NEW, and lowering the priority back to Normal. This is *not* a
common scenario. I'm also changing the summary of the bug to better describe the
problem, from:
  "Text selection does not work properly in multiline text boxes"
to:
  "Text selection does not work properly in RTL multiline textareas"

Prog.

Comment 17

[Prognathous]

Attachment: Text selection: IE6 vs. Mozilla 1.5

Comment 18

[Uri Bernstein]

This problem (as described in comment 16) is actually the same as bug 299527
(except here the shift key is pressed so selection is affected in addition to
caret movement).
Like bug 299527, this too should be fixed by the patch for bug 277553, if and
when it is checked in.
Marking dependency on both of these bugs.

Comment 19

[Uri Bernstein]

Fixed by the patch to bug 277553. Verified using an hourly build.

Comment 20

[(no longer active)]

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