The Shift-Down Arrow and Shift-Up Arrow key combinations highlight a line of text in the editing window at a time. This does not work correctly at the last and first line of text. To reproduce: 1. Open a new message compose window 2. Select the main text editing area 3. Type a few characters, without hitting return 4. Position the cursor in the middle of the line 5. Press Shift-Dn or Shift-Up Actual outcome: nothing happens Expected outcome: Shift-Down Arrow should move the cursor to the ned of the line and highlight the text between the original cursor position and the end of the line; similarly for Shift-Up Arrow and the beginning of the line. Observed on Linux build 1999112708, works in Navigator 4.7 for Linux.

Actually, down and up dont work as expected, not just shift-dn and shift-up: On the last line, down should take you to the end of the line; in the first line, up should take you to the beginning of the line.

zach - are you in html compose window or the plain text compose window? Thanks for reporting these bugs!

Works in neither HTML nor plain text.

I see this on Mac so reset platform/os to ALL. This applies to mail compose, editor, text widgets (all editing types). Reset to Browser/Selection and reassign to mjudge.

moving to M13 for now

change qa contact to sujay since this is in editor (outside of mail)

This looks like a direct counterpart, referring to keyboard selection rather than to drag-selection, to bug 19191 "[Mac] Text selection not per HIG (not selecting entire line)" where dragging up from the middle of the first (or any) line past the top of the editing area (or the equivalent downwards) does not select all of the first line, as Mac users would expect it to. A partial fix is available for that bug in the form of a hidden prefs.js preference; it does work. The key here is that while on MS-Windows both vert. drag-selection and [Shift]+[Dn]-selection select to the same position in the next (or previous) line, the Mac HIG states that drag-selection should select to the next line, or the beginning or end of the line if the boundary of the editing area is reached first. Obviously, if the selection works *only* to the same position in the next (or previous) line, and there is no next or previous line, no further selection (if any) will be possible. It appears that some platforms (some or all X window managers? Mac?) by default support keyboard-selecting to the beginning or end of a line using [Shift]+[Up] and [Shift]+{Dn] if there is not another line in that direction, and moving to the beginning or end of a line using [Up] or [Dn] if there is not another line in that direction, while others do not (MS-Windows). Neither NN 4.x nor notepad.exe on Win32 support those selection and caret-movement behaviors: nothing useful happens if there is not another line. I'm not certain about fixing this for MS-Windows: it appears to be broken in all Apps that derive their editing behaviors from the MFC (this goes all the way back to DOS EDIT.COM), and I for one have gotten very used to working around this bug in every other Windows app, so much so that I didn't know until testing this now that my main editor, Textpad, does work properly. On the other hand, I don't necessarily see a real problem on Win32 if this was fixed for ALL platforms, for that same reason. Cc-ing masri@nolex.com to confirm that the keyboard-selection behaviour that zach@math.berkeley.edu is expecting on Linux should also be expected on Macs.

I would be curious if other Linux applictions worked this way. See bug 19191 for my list of things I tested on the Mac, and see if you can come up with an appropriate list on Linux to prove that this behavior should be the norm on Linux. In most text areas I tested on the Mac (OS 9), this is not normal behavior. However, in AppleWorks, you can use shift-up and shift-down to do selections. Mac HIG states that if you can add interface features that extend the usefulness of your app for your users, while not violating known HIG rules, then the feature is a good one to add. So, if it's trivial to add it to text areas in Moz, this would be a nice feature on all platforms (as long as HIG on those platforms wasn't being violated), including Mac. It is possible that the previous version of Nav/Communicator you were using was actually breaking (or at least not following) HIG for X... - Adam

P.S. On Mac, text areas in Netscape Communicator 4.7 can be selected using shift- up and down areas from the selection point, but the URL bar at the top does NOT work this way. IMHO, this is an inconsistency. - Adam

this appears to be a problem with drag selecting now. I will turn on hidden preference on mac to get drag selecting snapping to end or beginning when dragging out of text area bounds. as far as shift selecting, the compose window now is working. aka VK_UP on first line will go to beginning of line. VK_DOWN on last line snaps to end of that line. on the url bar this should not happen as per the way 4.x works where up or down is forward or back in the url history. i am not sure if that last item is working on mozilla yet if not it should be another bug. I am resolving this after i check in the macintosh specific mouse code.

"on the url bar this should not happen as per the way 4.x works where up or down is forward or back in the url history." Huh? First off, we're talking about shift-up and shift-down, not just up and down arrows. Second, up and down arrow, or shift-up or shift-down arrow, do not move to a different URL on MacOS 9. Third, these inconsistencies between multi-line behavior and single-line behavior are, IMO, obnoxious. Even if 4.x works this way (which I don't see), let's get rid of all these inconsistencies, ok? - Adam

ok no worries. i can just set the mac to have single line text go to home or end depending on the up or down arrow. very simple. just change some JS.

ok akkana allready has a Up and Down mapping for single line text. i just added SHIFT up/down. i have fix in my tree will check it in as soon as tree opens.

ok this SHOULD work now on MAC as of 5 min ago 1-10-00. shift up,shift down now select to beginning and end of line respectively. I am resolving this bug with the understanding that if tomorrow's spin doesnt reflect this to our satisfactions, this bug should be reopened with and new problems added in the coments.

forgot to resolve it

verified in 1/12 build.

Testing bug 23983, I noticed that the behaviour that was asked for here for Mac only (and is presumably working now) is happening on Win32 in TEXTAREAs only. That is, from anywhere on the last line except at the very end, both [Dn] and [Shift]+[Dn] work exactly as if there were a blank line after the last line. The equivalent for the first line, as well. This does not work for <INPUT TYPE="TEXT"> on Win32. Tested with: 2000-01-20-08-M13 nightly binary on Windows NT 4.0sp3. Now, if this behaviour is wanted *only* on the Mac, I should file a bug report about the unexpected ability to select part or all of the first or last line of a TEXTAREA's contents with [Shift]+[Up] or [Shift]+[Dn] on Win32, but... I wonder, is there actually anything wrong with turning this on for all builds? It would appear to be a useful and distinctive addition to the Mozilla UI on all platforms. As discussed for the equivalent issue with drag-selection in bug 19191, it is natural to expect editing actions to work the same on the first, last, or only line as on a middle line. If this is made XP, then the new bug that would need to be filed would be a [PP] bug to get this working for <INPUT TYPE="TEXT"> on Win32. REOPENing for consideration; if this is left as Mac-only, this should obviously go back to VERIFIED FIXED, not to WONTFIX.

Clearing FIXED resolution due to reopen.

ok i am going to leave the behavior on text areas the same. down onlast line goes to end on windows. I will change the problem with down not moving 1 character to the right on single line text. up moving left one char. this will be easy fix.

Per pdt, not critical for M13, moving to M14.

I have fix in my tree. simple change to js for inputBindings. will sit on it till we open m14. unless someone REALLY wants it for m13 for some reason..

works now on windows properly it seems. unix supposedly has also updated the xbl .xul files so all that is left is mac for kathy(she checkin in on monday the 14th) . if problem with linux bindings file new bug on akkana. if problem with mac bindings file with brade. if problem with windows please open a new bug on me.

Kathy was supposed to checkin a fix for this on Monday. Nothing has been listed on this bug from Kathy that this was fixed; therefore, I'm reopening it. Once Kathy's made a note that the Mac version has this bug fixed, then we should verify fix it again. I'm afraid I don't understand why this bug was resolved fixed anyway, seeing how the Mac platform fix hadn't been checked in. Thanks for checking on this. - Adam

Resolving this bug as fixed. Mike filed a new bug for the mac specific fixes that needed to go in. I made my comments in the new bug. I checked it in a few days ago.

The new mac bug is #27447

Verified on Linux build 2000.02.17.15

verified in 2/21 build.