Closed Bug 46811 Opened 24 years ago Closed 23 years ago

Up/Down arrow keys should move to start/end of first/last line

Categories

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

Product:
Core
Component:
DOM: Editor
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: Brade, Assigned: mjudge)

References

Details

(Keywords: helpwanted, Whiteboard: FIXINHAND waiting for tree to open)

Attachments

(1 file)

removing an else statement to force failures into the fail safe mechanism
579 bytes, patch
Details | Diff | Splinter Review 
I can't use the up arrow to move the caret in the urlbar.  Instead of letting me
adjust the selection the caret always goes to the end of the url.  This is very
confusing.

load http://bugzilla.mozilla.org/
select "mozilla"
press the up arrow

notice that the caret is blinking at the end of the url instead of at the
beginning of the selection (between the '.' and the 'm').

This works properly in Composer.
add 4xp, dogfood and nsbeta3 keywords
In 4.x on Macintosh I can press the up arrow and have the caret move to the
beginning of the urlbar.  The urlbar should be similar to regular text widget
keybindings.

Note:  this is dogfood for me since it makes it nearly impossible to edit a url
if the arrow keys don't work as expected.
Severity: normal → major
Keywords: 4xp, dogfood, nsbeta3
Up arrow should be handled by the editor controller, and mjudge's caret moving 
code. This is entirely an editor issue.

When I try this, I see the caret jump to the start of the field, and then back to 
the end.
Assignee: radha → mjudge
Component: History → Editor
Summary: can't use up arrow to move caret in urlbar → Up arrow key in text field should move caret to start
brade...what build are you using?  I think you are on Trunk M18 build?
Whiteboard: [NEED INFO]
I see this in build 2000072708, which probably means it is on the branch and trunk.

...but... I'm not in a triage meeting... and just commenting for consideration....

IMO, this is a real non-issue.  I tried this in 4.x, and you can't use (on
windows) the up and down arrow key to navigate in the URL bar.  You can use the
left and right arrows, and they work equally well on Nav 6.  Certainly this
should not IMO stop nsbeta2 in any way.

I was surprised to hear that an "up arrow" should bring the cursor to the start
of the field... and I'm really curious to understand why this navigation issue
would be a dogfood quality bug.  Does it really stop folks from using the product?
I don't think this should stop beta2.
I do think that it's *VERY* bizarre to press the up arrow and have the caret go 
to the end (and only in the urlbar not in other edit fields).  I use the up arrow 
very often for editing text in editfields.  In 4.x the up arrow works as I expect 
it to (on Macintosh); I don't know about the Windows 4.x version.  In my case, 
this is dogfood since I always edit the url string and I rely on the arrow keys 
not doing surprising things.

As originally stated, this is NOT an editor bug; it's a history bug.
Reset to appropriate category/assignee/etc.
Assignee: mjudge → radha
Component: Editor → History
Whiteboard: [NEED INFO]
Putting on [dogfood-] radar.  Not critical to everyday use.
Whiteboard: [dogfood-]
IMO, using the up and down arrows in this way(and other related behaviors) is a very MAC thing and I use it  _all_the_time_ 
because so many apps support it. While it's probably not a dogfood issue it is very high on the irksome chart.

nav triage team:
this is really annoying on Mac because it is standard behavior, but oh well
Whiteboard: [dogfood-] → [dogfood-][nsbeta3-]
Based on comments by simon on 7/28, giving to editor team
Assignee: radha → beppe
Component: History → Editor
Assignee: beppe → mjudge
Keywords: helpwanted
Target Milestone: --- → Future
setting to future
This applies to the Down arrow key as well. When the caret is in the first line
of the field and the Up arrow key is pressed, the caret should go to the start
of that line; when the caret is in the last line of the field and the Down arrow
key is pressed, the caret should go to the end of that line (*as well as*
opening the auto-complete menu, if there is one for that text widget).

Of course in a single-line text field, `the first line of the field' and `the
last line of the field' are exactly the same thing, but that shouldn't need any
special code beyond that applied to textfields in general. Curiously, though,
this works in most XUL textfields (build 2000102008, Mac OS 9.0), but not in the
location field or in HTML textfields. So it looks like the current fix is in the
wrong place, or is overly specific, or something like that.

In HTML textfields Up and Down do nothing; in the location field, the contents
of the field is obliterated and there is no way to get it back.
Summary: Up arrow key in text field should move caret to start → Up/Down arrow keys should move to start/end of first/last line
Depends on: 51126
nominate for a fix on the mozilla trunk (prior to mozilla 1.0).  This is still a
dogfood issue for Macintosh users.  (I'm not sure why this is ALL platforms/OS.)

We need to fix this behavior for single-line inputs as well as textareas and in
Composer (the urlbar, specifically, may be considered "special" due to some
truly wacky behaviors specified by UE (???)).
Keywords: nsbeta3
Whiteboard: [dogfood-][nsbeta3-]
Target Milestone: Future → mozilla0.9
*** Bug 51126 has been marked as a duplicate of this bug. ***
Just want to add that this should never happen on Windows. For Windows users 
(not Mac people using Windows) this would be very bizarre behavior. Up arrow 
when there is nowhere to go up should do nothing. Windows users are accustomed 
to using the appropriately named HOME and END keys.
Hrm, I like the behavior that you escribe. I am annoyed by the fact that
pressing the up/down arrows in the url bar change the url instead of going to
the beginning/end of it. This should be a preference item, as well as the nasty
autocomplete stuff.
*** Bug 64872 has been marked as a duplicate of this bug. ***
urlbar issues aside, can we get the arrow keys to work properly in other edit 
fields?  It does seem to work properly in Composer.
Keywords: nsmac1
*** Bug 69110 has been marked as a duplicate of this bug. ***
moveing to .091
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9 → mozilla0.9.1
ok i have a fix for this. the problem was the down arrow was looking outside the 
area of the text field. then it would later fail of course but it didnt then 
drop to the "if down fails then goto end of line" code. i just removed an else 
and changed it to always check result.  i will run more tests then i will post a 
patch.
fix in hand
Whiteboard: FIXINHAND needs review
Whiteboard: FIXINHAND needs review → FIXINHAND waiting for tree to open
fixed
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
QA Contact: claudius → sujay
verified.
Status: RESOLVED → VERIFIED
Mass removing self from CC list.
Now I feel sumb because I have to add back. Sorry for the spam.
This bug is not fixed in Firefox 1.0, Thunderbird 1.0, or Mozilla 1.7.5. Please
re-open this bug.
The irony is that it still "works" on Windows where it shouldn't be happening in
the first place.
Dan Roca (comment 26) -- please file a new bug (please cc me too).  What you are
seeing is a regression (not the original bug described in this bug which is an
editor core or selection issue).  In general bugs that are resolved and verified
over 6 months ago should not be reopened.

For the record, Firefox 1.0 seems to work fine in textareas but not in input
fields.  I'd guess a resource file is missing or someone deleted the crucial
keybindings.

Mozilla 1.7.3 on Mac behaves properly in both input and textarea fields.

Jerry Baker (comment 29) -- I don't understand your comment at all.  Please
clarify in a new bug if there is an issue/bug.  Thanks!
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: