Closed Bug 20146 Opened 25 years ago Closed 25 years ago

Compose: Down arrow and Up arrow don't work on last and first line

Categories

(Core :: DOM: Selection, defect, P3)

Product:
Core
Component:
DOM: Selection
Type:
defect

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: rzach, Assigned: mjudge)

Details

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.
Summary: Shift-Dn and Shift-Up don't work on last and first line → Down arrow and Up arrow don't work on last and first line
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!
Summary: Down arrow and Up arrow don't work on last and first line → Compose: Down arrow and Up arrow don't work on last and first line
Works in neither HTML nor plain text.
Assignee: ducarroz → beppe
Assignee: beppe → mjudge
Component: Composition → Selection
OS: Linux → All
Product: MailNews → Browser
Hardware: PC → All
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.
Target Milestone: M13
moving to M13 for now
QA Contact: lchiang → sujay
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
Status: NEW → ASSIGNED
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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → VERIFIED
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.
Status: VERIFIED → REOPENED
Clearing FIXED resolution due to reopen.
Resolution: FIXED → ---
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.
Status: REOPENED → ASSIGNED
Per pdt, not critical for M13, moving to M14.
Target Milestone: M13 → 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.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
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
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → FIXED
The new mac bug is #27447

Verified on Linux build 2000.02.17.15

verified in 2/21 build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.