problems with first impl. of home/end keys

RESOLVED FIXED in M16

Status

()

Core
Selection
P3
normal
RESOLVED FIXED
19 years ago
18 years ago

People

(Reporter: buster, Assigned: mjudge)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
open the editor test page
in the default window size, the 2nd paragraph has 2 lines
home/end work great on the first line
put the caret int the second line
home gets you to the space that ends the first line, instead of in front of the
first character of the second line.
-------
put the caret in "Reruns are about as much fun,"  end doesn't work at all
-------
put the caret in "There are 4 br tags on either side of this sentence" end
doesn't work at all
-------
home/end act very screwy in tables.  cells in the first column seem to work. but
second colum only home works correctly, end only moves the select part way
towards the end of the line. and in cells in the third column, both home and end
go to the beginning of the line.
(Reporter)

Updated

19 years ago
Summary: problems with first impl. of home/end keys → problems with first impl. of home/end keys
Target Milestone: M12

Comment 1

19 years ago
Adding cpratt (keyboard navigation.)

I'm confused. Why do the Home and End keys move the cursor to the beginning or
end of a particular line? This is not consistent with any platform UI guidelines
that I know of, and specifically violates the Mac OS UI Guidelines:

----

http://developer.apple.com/techpubs/mac/HIGuidelines/HIGuidelines-
214.html#HEADING214-0

Home

  Pressing the Home key is equivalent to moving the scroll boxes all the way to
the top of the vertical scroll bar and to the left end of the horizontal scroll
bar. (Note that the Home key may operate differently in a spreadsheet
application; it won't necessarily scroll horizontally and it may scroll to the
beginning of a row or to the beginning of the spreadsheet itself.)

Pressing the Home key has no effect on the location of the insertion point or any
selected material.

  End

  Pressing End is the opposite of pressing Home: it's equivalent to moving the
scroll boxes all the way to the bottom of the vertical scroll bar and to the
right end of the horizontal scroll bar. (Note that the End key may operate
differently in a spreadsheet application; it won't necessarily scroll
horizontally and it may scroll to the end of a row or to the end of the
spreadsheet itself.) Pressing End has no effect on the location of the insertion
point or any selected material.

Comment 2

19 years ago
elig, the behavior as described in this bug seems absolutely correct in terms of
expected behavior on (at least) Win32 text editing applications such as Notepad,
WordPad, or Word 97.

home/end do very different things when used in contexts that have naught to do
with text editing, such as in Web browsers (but not in text input controls).
there, home should take you to the top of the page, and end should take you to
the bottom of the page - unless you're in a text input control, in which home
should take you to the beginning of the line, and end should take you to the end
of the current line.

I did file bug 12213 in hope of getting Home working (in non-text input areas of
the browser) in 5.0. (It does not work in legacy Netscape browsers.)

for curiosity's sake, what's the behavior in Mac apps such as AppleWorks or
SimpleText?
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 3

19 years ago
ok eli 'here is the deal'  home and end on windows are harder to implement than
the scrolltotop and scrolltobottom as it happens on mac. the default therefore
is the windows way for now until we get the keybindings working.  that said,
this bug is now fixed. i can home/end on any line given in below examples.
horay! (BTW eli PageUp and PageDown fall under this category of scrolling on mac
and scrolling/moving cursor on windows and X)

Updated

19 years ago
Status: RESOLVED → REOPENED

Updated

19 years ago
Resolution: FIXED → ---

Comment 4

19 years ago
This is definitely improved. Unfortunately, the table cell Home/End issues that
buster described are still present in all builds checked:
     1999100708 Mac OS & Linux
     1999100708 Win32

Thus, re-opening for the Judgester.

Updated

19 years ago
Status: REOPENED → ASSIGNED

Comment 5

19 years ago
I checked this out ousing the 10/12/99 build on win95, the really starnge thing
is that selecting Home placed the cursor to the far right, or the end of the
line. Selecting End placed the cursor 2 characters in from the left. In a table,
selecting either Home or End placed the cursor at the end of the line.

Setting this to M15, this can wait till after beta push

Updated

19 years ago
Target Milestone: M12 → M15

Updated

19 years ago
Target Milestone: M15 → M16

Comment 6

19 years ago
moving to m16 - load balance

Comment 7

19 years ago
*** Bug 22766 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 8

18 years ago
this is fixed. home/end in tables ect now works.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago18 years ago
Resolution: --- → FIXED

Comment 9

18 years ago
*SPAM*: Changing the QA contact of all open/resolved Selection bugs from 
elig@netscape.com to BlakeR1234@aol.com.  After the many great years of service 
Eli has given to Mozilla, it's time for him to move on; he has accepted a 
position at Eazel.  We'll be sad to see him go, and I'll do my best to fill his 
spot...
QA Contact: elig → BlakeR1234
You need to log in before you can comment on or make changes to this bug.