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)
SeaMonkey
Location Bar
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.
Updated•25 years ago
|
Assignee: joki → rods
Comment 1•25 years ago
|
||
Taking this from Tom, at Tom's request
Updated•25 years ago
|
Assignee: rods → buster
Comment 2•25 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•25 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•25 years ago
|
Assignee: buster → mjudge
Comment 4•25 years ago
|
||
reassign to mjudge@netscape.com
Comment 5•25 years ago
|
||
adding to the event handling tracking bug
Updated•25 years ago
|
Summary: Inconsistent behavior when cursor keys used in Location: control → Inconsistent behavior when arrow keys used in Location: control
Comment 6•25 years ago
|
||
Changing summary from "cursor" to "arrow"
Updated•25 years ago
|
Target Milestone: M15 → M16
Comment 7•25 years ago
|
||
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
Comment 9•24 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•24 years ago
|
||
doh! brain took a vacation. I can too change the "assigned to" field.
Assignee: mjudge → radha
Status: REOPENED → NEW
Comment 11•24 years ago
|
||
nav triage team: german: can you confirm what the UE opinion on this is. P2 for next Beta. thanks.
Keywords: nsbeta1
Priority: P3 → P2
Comment 12•24 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•24 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•24 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 → ---
Assignee | ||
Comment 16•24 years ago
|
||
moving these bugs to History: URLBar
Assignee: radha → alecf
Component: History: Session → History: URLBar
Assignee | ||
Updated•24 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.0
Comment 17•24 years ago
|
||
Removing nsbeta1+ status whiteboard, changing nsbeta1 keyword to nsbeta1+
Comment 19•23 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•23 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
Closed: 24 years ago → 23 years ago
Resolution: --- → WORKSFORME
Reporter | ||
Comment 21•23 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
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•