Inconsistent behavior when arrow keys used in Location: control

VERIFIED WORKSFORME

Status

SeaMonkey
Location Bar
P2
minor
VERIFIED WORKSFORME
19 years ago
10 years ago

People

(Reporter: cpratt, Assigned: Alec Flett)

Tracking

({access})

Trunk
mozilla1.0
access

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

19 years ago
Build ID: 19990630**
Platform: Win32, Linux, Mac OS

To reproduce:
- Click into the Location: control and position the insertion cursor to the left
of the URL.
- Press the down arrow key.

Result:
All three platforms behave differently. On Win32, the cursor moves to the right
once for each press. On the Mac, the cursor moves to the end of the URL. On
Linux, focus is lost.

Expected result:
Frankly, I'm not sure what the expected result is. I'm guessing that the
(currently) expected result is the Mac behavior: that the cursor moves to the
end of the URL. In the future, I'm guessing that the expected result would be to
move up and down along the list of visited URLs.

Updated

19 years ago
Assignee: joki → rods

Comment 1

19 years ago
Taking this from Tom, at Tom's request

Updated

19 years ago
Assignee: rods → buster

Comment 2

19 years ago
Steve, this is an edit control bug that does not have to do with resizing. It
actually may even be fixed, because I am not seeing the described behavior on NT

Comment 3

19 years ago
on Mac, the current behavior is to not move the caret with up/down arrows.  I
would consider that a bug since the caret should move to the beginning/end of the
line.

Updated

19 years ago
Assignee: buster → mjudge

Comment 4

19 years ago
reassign to mjudge@netscape.com

Updated

19 years ago
Blocks: 15693
Target Milestone: M15

Comment 5

19 years ago
adding to the event handling tracking bug

Updated

19 years ago
Summary: Inconsistent behavior when cursor keys used in Location: control → Inconsistent behavior when arrow keys used in Location: control

Comment 6

19 years ago
Changing summary from "cursor" to "arrow"

Updated

19 years ago
Target Milestone: M15 → M16

Comment 7

19 years ago
moving to m16 - load balance

Comment 8

18 years ago
this works the way that edit fields natively work on these platforms i believe. 
please give examples where this is wrong. I am listing this as fixed. open up 
platform specific bugs on those platforms behaving badly
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 9

18 years ago
WinNT
ACTUAL: Up/down arrow keys delete the url.  Even reloading does not bring 
it back.  Left/right arrow keys go left or right by one char.

Win98
ACTUAL: Up/down arrow keys do nothing.  Left/right arrow keys also do 
nothing.

Linux
ACTUAL: Up/down arrow keys both go to the last url in history. Left/right arrow 
keys go left or right by one char.

Mac
ACTUAL: Up/down arrow keys delete the url.  Even reloading does not bring 
it back.  Left/right arrow keys go left or right by one char. (Same as NT)

EXPECTED on all platforms: 
Up/down arrow keys should move backward or forward 1 URL at a time through 
history.  Left/right arrow keys go left or right by 1 char.

reopening bug.  Changing component to history. I think this should go to radha, 
but I can't change the assigned to field.  Adding radha onto cc list. (Apologies 
if these changes are incorrect.)
Status: RESOLVED → REOPENED
Component: Event Handling → History
Resolution: FIXED → ---

Comment 10

18 years ago
doh! brain took a vacation.  I can too change the "assigned to" field.
Assignee: mjudge → radha
Status: REOPENED → NEW
nav triage team: german: can you confirm what the UE opinion on this is. P2 for 
next Beta. thanks. 
Keywords: nsbeta1
Priority: P3 → P2
Keywords: access

Comment 12

18 years ago
Nominating for Mozilla 0.9.1 because this is an important keyboard accessibility
issue and therefore should be fixed before Mozilla's 1.0 release.

The target milestone is in need of updating.
Keywords: mozilla0.9.1

Comment 13

18 years ago
On Windows, Up and Down should do nothing. (Replacing the current contents of the 
field with previous/next history values would be more confusing than useful.) On 
other platforms, Up and Down should go to the beginning/end of the field. This is 
the expected behavior for any textfield, so this bug should really be in
`XP Toolkit: Widgets' rather than `History'.

Comment 14

18 years ago
Up and down on windows should drop down the history list.  Yes they shouldn't 
automatically navigate, but they should drop it down.

zapping m16.
Target Milestone: M16 → ---

Comment 15

18 years ago
nav triage team:

Marking nsbeta1+
Whiteboard: nsbeta1+
(Assignee)

Comment 16

18 years ago
moving these bugs to History: URLBar
Assignee: radha → alecf
Component: History: Session → History: URLBar
(Assignee)

Updated

18 years ago
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0

Comment 17

17 years ago
Removing nsbeta1+ status whiteboard, changing nsbeta1 keyword to nsbeta1+
Keywords: nsbeta1 → nsbeta1+
Whiteboard: nsbeta1+

Comment 18

17 years ago
not my area, reassigning to gerardok
QA Contact: janc → gerardok

Updated

17 years ago
QA Contact: gerardok → claudius

Comment 19

17 years ago
On Windows, this now drops down the autocomplete box, or navigates into it.

Does it do this on other platforms now? Is it now consistent?

Comment 20

17 years ago
nav triage team:

hitting down in the url bar on all platforms no drops down the auto complete
widget, marking worksforme
Status: ASSIGNED → RESOLVED
Last Resolved: 18 years ago17 years ago
Resolution: --- → WORKSFORME
(Reporter)

Comment 21

17 years ago
Wait two years three weeks on most bugs and WORKSFORME does become a valid 
resolution. I'll just assume Paul's right and verify this as such.
Status: RESOLVED → VERIFIED
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.