Closed Bug 151999 Opened 18 years ago Closed 14 years ago
Text selection does not work properly in RTL multiline textareas
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
reassign to editor
Assignee: ducarroz → kin
Component: Composition → Editor: Core
Product: MailNews → Browser
QA Contact: esther → sujay
--> mjudge (selection/caret navigation)
Assignee: kin → mjudge
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 ?
Bug remains in effect, at least for RTL text (I use Hebrew) - there have been no changes over the past year in this respect.
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.
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.
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.
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.
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.
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.
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'.
Severity: normal → major
Sorry for spamming, but maybe a name change is also in order...
Summary: text selection does not work when composing a message → Text selection does not work properly in multiline text boxes
> 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.
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.
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.
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.
Severity: major → normal
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Text selection does not work properly in multiline text boxes → Text selection does not work properly in RTL multiline textareas
Whiteboard: Please read comment #16 for steps to reproduce this bug
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.
Fixed by the patch to bug 277553. Verified using an hourly build.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.