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.
Taking this from Tom, at Tom's request
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.
reassign to email@example.com
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"
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
Last Resolved: 18 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.
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.
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+
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: nsbeta1 → nsbeta1+
not my area, reassigning to gerardok
QA Contact: janc → gerardok
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
Last Resolved: 18 years ago → 17 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
You need to log in before you can comment on or make changes to this bug.