Closed Bug 9088 Opened 25 years ago Closed 23 years ago

Inconsistent behavior when arrow keys used in Location: control

Categories

(SeaMonkey :: Location Bar, defect, P2)

Tracking

(Not tracked)

VERIFIED WORKSFORME
mozilla1.0

People

(Reporter: cpratt, Assigned: alecf)

References

Details

(Keywords: access)

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.
Assignee: joki → rods
Taking this from Tom, at Tom's request
Assignee: rods → buster
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
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.
Assignee: buster → mjudge
reassign to mjudge@netscape.com
Blocks: 15693
Target Milestone: M15
adding to the event handling tracking bug
Summary: Inconsistent behavior when cursor keys used in Location: control → Inconsistent behavior when arrow keys used in Location: control
Changing summary from "cursor" to "arrow"
Target Milestone: M15 → M16
moving to m16 - load balance
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
Closed: 24 years ago
Resolution: --- → FIXED
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 → ---
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
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
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'.
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 → ---
nav triage team:

Marking nsbeta1+
Whiteboard: nsbeta1+
moving these bugs to History: URLBar
Assignee: radha → alecf
Component: History: Session → History: URLBar
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Removing nsbeta1+ status whiteboard, changing nsbeta1 keyword to nsbeta1+
Keywords: nsbeta1nsbeta1+
Whiteboard: nsbeta1+
not my area, reassigning to gerardok
QA Contact: janc → gerardok
QA Contact: gerardok → claudius
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?
nav triage team:

hitting down in the url bar on all platforms no drops down the auto complete
widget, marking worksforme
Status: ASSIGNED → RESOLVED
Closed: 24 years ago23 years ago
Resolution: --- → WORKSFORME
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.