Closed Bug 19446 Opened 25 years ago Closed 24 years ago

RFE Key-combo to move focus to URL Bar and select contents (Accel+L)

Categories

(Core :: DOM: UI Events & Focus Handling, enhancement, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
enhancement

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.2

People

(Reporter: sidr, Assigned: bugzilla)

References

(Blocks 1 open bug)

Details

Overview: There are circumstances in which it would be handy to be able to move the focus to the Location Bar without using the mouse. Once there, it would be helpful to be able to navigate the Location Bar history by using the cursor keys, as is possible with a <select> form control. Scenario 1: Arriving at his desk the office, J. Q. Public still has a sugared donut in his mousing hand. Sure, he could finish it first, or use the other hand, but why not use the keyboard to get to the location bar and then do a one-handed hunt-and-peck? Scenario 2: Back at home, J. Q. Public is eating pizza/fries/popcorn/whatever when reminded of a URL he'd forgotten to remember, and wants to go check it out without taking time to clean his eating hand. Scenario 3: Actually doing some work for a change, our hero J. Q. Public, who can touch-type, is composing some e-mail when he realizes that he's better check a fact before firing it off. He's been meaning to re-arrange the computer area to make the mouse handier, but hasn't gotten around to it. ALT-TAB brings up the browser, but, grumble, time to reach for the mouse to get to the location bar. Of course, none of this is *necessary*: File>Open Web Location substitutes perfectly, and the History is also accessible, but the Location Bar is so out-in-the-open that it is easy to forget that it's possible to do these things using the Menus, if the user ever learned that. ALT-L (Command-L, Meta-L) seems to be available, and for browser users, the Location bar is at least as primary as a menu, and with the history drop-down, even is a menu of sorts. I'm quite certain that this would get used. IE5 uses ALT-D for "aDdress" for the same purpose, but I didn't know that before starting to write this up - I just know that I've wanted to be able to do this off-and-on for as long as graphical browsers have been available.
Assignee: shuang → lake
please use bug writing guildline to write the bug (check out http://www.mozilla.org/quality/bug-writing-guidelines.html) for details. Also reassign it to lake. I don't think we do any special treatment for location bar history list, it should be treated as navigating normal HTML page. Lake?
Summary: Key-combo to move focus to Location Bar ( ALT+L ? ) → RFE: Key-combo to move focus to Location Bar ( ALT+L ? )
My bad, forgot to mark the summary line RFE to match the Severity, and I know I got too chatty. Another aspect: this has implications for accessibility. For example, someone who many days can use a mouse but sometimes has too much hand-shaking, may be able to use the suggested functionality to work with the Location Bar with keystrokes only on those days, and not be forced to work in a comletely different manner (File>Open Web Location). This is rather a stronger argument than any of the scenarios above makes.
Thanks for your comments. You are not the only one who thinks this would be a good idea. We do too. For web pages we intend the jump to Location Bar will be keyboard acessable in two ways; one where the user can cycle through frames instead of cyceling through each item in the web page (probably ctrl+tab) this will likely reduce the keystrokes from th 20s to 3 or less. Alternatly by a key combination (perhaps Shift+ctrl+Tab)to go directly there. There are a few issues to hammer out before this is finalized. And these examples may not be the final plan. The issue of how to access the keystroke history in the Location Bar will probably work similarly to the current 4.x incarnation where the URL bar has the focus Alt+arrow up/arrow down) drops the list box and the arrow keys change the focus.
Status: NEW → ASSIGNED
This RFE was opened for a simple keyboard-only way to go directly to the Location bar *only* no matter where the focus is at the time. If keyboard navigation using arrowkeys, PgUp & PgDn, spacebar etc. is going to be useable, focus needs to be at the top of the page after page loading (there is already a bug open on this), so there needs to be some way to move it to the location bar on demand - and for optimum useability the user should be able to depend on the Location bar *always* having focus after that keystroke. "Shift+ctrl+Tab" does not seem to be a good keystroke for that, for reasons given below. (1) shift+ctrl, shift+tab, and ctrl+tab all have distinct, existing, well-established meanings - and going directly to the Location Bar is not a natural extension of any of those. (2) anything+TAB is going to imply serial navigation for anyone used to using TAB, shift+TAB, ctrl+TAB, and alt+TAB - for that reason shift+ctrl+TAB would imply alternation between the current position in the document and the Location bar, even if it doesn't do that. Not to have it alternate would be confusing, but if it alternated, the user could not be *certain* that the next keystroke would go to the Location bar and nowhere else. (3) "Shift+ctrl+Tab" would not be the easiest to type for anyone with even a slight physical infirmity involving precise positioning of the fingers of the left hand, even if "stickykeys" are used... and direct navigation (as opposed to serial navigation) is recommended especially for users with physical problems in the W3 Accessibility Guidelines (Sec. 7.4 under http://www.w3.org/TR/WAI-USERAGENT/#gl-accessible-interface ) - some of these people would have trouble with that sort of key-combo. So I repeat my proposal: if anything deserves as high a priority for keybindings as the menubar menus in a web browser, it is the Location bar -- ALT+L makes sense to me. Based on earlier comments, TAB, shift+TAB, and ctrl+TAB would all serve to return to the webpage if the user decided not to enter an new URL after all.
Moving UE/UI component bugs over to new User Interface: Design Feedback component. UE/UI component will be deleted.
Component: UE/UI → User Interface: Design Feedback
Does not the latest version of HTML or XHTML or something allow accelerator keys for form fields? I thought that I had read that some time back. If so, you can't really use Alt in combination with anything, as that may potentially be an accelerator to a form field (eg. &Last Name:). How about a Ctrl shortcut, or a Ctrl+Shift one?
The Open Location dialog can be simply replaced with location bar focusing (and showing if otherwise hidden). The access key could then be Ctrl-L. After all, who need the dialog if you can move the focus to te location field using the keyboard?
What Henri suggested -- Ctrl+L to give the location bar focus -- is what is done by IE 5 for MacOS (and will eventually be done by Aphrodite too, if it isn't already). It also removes the clutter of an extra `Open Location' item from the File menu. (For the die-hards who like a separate Open Location dialog, IE 5 provides Ctrl+Shift+L for that.)
Except for those people that use "Open in New Window" or "Open in Composer". I don't, but someone must.
If you need a new window, you can use ctrl-N first. It should be easier than modifying the options in the dialog from the keyboard. I don't believe users open remote pages in Composer/Editor by typing in a URL.
Wait, in most cases hitting TAB for the first time on a page jumps to the location bar and selects the url. At least in win32 it does. Is this being abandoned? I've grown quite used to it and use it a lot. As for the appropriate accelerator, how about using the biggest button on the keyboard, the ctrl-spacebar?
Moving to more-appropriate "Keyboard Navigation" component. Ctrl-spacebar isn't a half-bad idea. The spacebar is the only key that is known as a navigation key (if only in contexts where text editing isn't possible) other than the arrow/paging keys and TAB. Lakespur, thinking of the complex usage for ctrl+tab discussed in bug 30864, "Can't use Ctrl+Tab to quick-switch to next window", I'm wondering if it might not be worth considering using ctrl+space to cycle among the location bar, sidebar, content area and frames, so that ctrl+tab would not need to be overloaded for both that purpose and cycling through open windows. Ben, the point of this RFE is to have some way of quickly and easily getting focus back to the Location bar when it has been moved somewhere else first.
Component: User Interface: Design Feedback → Keyboard Navigation
QA Contact: claudius → szhu
Summary: RFE: Key-combo to move focus to Location Bar ( ALT+L ? ) → RFE Key-combo to move focus to URL Bar (ALT+L/ctrl-space?) (Location bar)
Cmd+spacebar is reserved on Mac OS for switching between keyboard layouts.
*spam* changing all open or resolved bugs that szhu@netscape.com was the QA contact for to sairuh@netscape.com. szhu is no longer with netscape, and these bugs could lie dormant otherwise. sorry for spam.
QA Contact: szhu → sairuh
Blocks: 55416
Ben, check out bug 31809 for the tab thing.
Blocks: 37587
Blocks: 67414
Nominating for nsbeta1. This bug is very annoying in combination with bug 57507. I'd like it if this shortcut would always select the contents of the location bar, even if the location bar already has focus. Today I was using IE (which has Alt+D for focusing the address bar) and couldn't figure out why Alt+D, Shift+Insert, Enter wasn't going to the page in my clipboard until I realized that Alt+D does nothing when the address bar is focused.
Keywords: nsbeta1
->german.
Assignee: lake → german
Status: ASSIGNED → NEW
Alt+A and Alt+C are other possibilities (loCAtion).
Chances are the "best" way to fix that bug would be to fix bug 959 to allow the location bar to have an accesskey, and bug 64606 to make that accesskey work from anywhere in the browser (instead of only from the toolbar). Those bugs might not be fixed soon, though, so it might be worthwhile to implement a hacky solution to this bug until those are fixed.
I have a fix that gives focus to the URLBar, I've also added accesskey. The current key I'm using is VK_F12, the F12 function key. Originally I'd tried to use Control+'/' as Control+l is currently Open URL, however, current bugs in the way Control,Alt states are managed on Win32 means that doesn't work at all. I'm investigating that today. The reason for my original choice of Control+'/' was accessability, the combination are close to one another on most 102 keyboards, though not all, and the '/' is a reasonable mnemonic for a URL.
Simon, Hi all, How about make a change - have Control-L highlight the URL bar, and move the old Control-L "Open location" dialog to Control-Shift-L. This is consistent with mpt's statements, I like it as well. The common thing people really want is just type in a new URL and load it, and going straight to the URL bar is the fastest way to do that. Therefore we should save the easy keystroke for the common thing, and use the related Control-Shift-L keystroke for the dialog version. It has also been suggested that there will be a location toolbar in mailnews, if you don't want the folder pane open all the tim, and that Control-L would access it. This would make Control-L consistent across both apps. Aaron
Simon, What happens if the URL bar is collapsed, and they press the access key? Aaron
I can't really fault the logic of moving Ctrl+L to Ctrl+Shift+L even if I prefer Ctrl+/ :-) As for when its a collapsed bar, is opening the bar what the user would expect, or is their requirement for more screen real estate a more important consideration? If the latter is true then the Open URL dialog should happen rather than popping open the toolbar.
sorry, but i don't want accel+L to change its current designation of Open Web Location dialog. i use it quite a bit!
I could go with Ctrl+L for focusing the location bar in Navigator. In that case, both Ctrl+L and Ctrl+Shift+L should open the location dialog in MailNews, since it doesn't make sense to have a location bar in MailNews. What happened to Alt+letter (Alt+L?), though? Alt+letter is usually used to focus things (or open menus) on Windows. Was the problem that unix doesn't reserve an alt for menus and focusing? (It might be necessary to define a different key on unix.)
jesse, are you asking about alt+L as an access key [mnemonic], or as an accelerator [shortcut]? if the former, nevermind, but if the latter: in 4.x it was the accelerator to Open Web Location, and alt+L was the same as alt+O [weird, but true]. because of this, i'd rather not bind alt+L to an accelerator since it could clobber users who set their accelerator key to Alt. [hrm, apologies if i misunderstood your question, tho'!]
Alt+L would be a mnemonic. I think Unix users who use Alt for accel already give up mnemonics, but I'm not sure.
actually, ctrl-l could go to folder list (either the drop down toolbar or the tree)...
hokay, after chatting with akkana and aaron, i could adapt to using accel+L to go to the URL bar iff it selects its contents. in a way, this would also complement my desire for "single click in URL Bar by default puts the cursor where you clicked", rather than doing a select all upon single click. [this is covered by seperate bugs, at least bug 8894 for starters. ;)] as i've mentioned elsewhere, having a hidden pref to toggle this would be fine...
Ok, regardless I think it probably needs to be in the platform overlay so that different platforms can have their own particular keystroke for when people squeal as they undoubtedly will. accel+L then?
See http://www.mozilla.org/projects/ui/accessibility for more info on current assignments. Giving ownership of this bug to aaronl for review, since he is coordinating the work on this very thing right now.
Assignee: german → aaronl
Right, a consensus was reached: Accel+L = focus on URL bar Accel+Shift+L = open location dialog If the URL bar is hidden, it should become visible when Accel+L is typed. Anyone willing to take this on in the code?
I will.
Assignee: aaronl → blakeross
You rock.
Not to be a trouble maker, but.... a big reason for the "open location" dialog box is because it's one key quicker to get an url open in a new window. With NS4.x, you would have to hit ctrl-N, then tab or whatever to type in the new address, so ctrl-l is faster. In the UI newsgroup, German Bauer's new location bar proposal prompted Chris Hill to suggest that hitting ctrl-N automatically focus the location bar, with the url selected. So then you could hit ctrl-N, type, hit enter, just as fast, and there's no location dialog box and ctrl-L could be a shortcut to get to the location bar with no need for modifiers. Seems like a win-win solution to me.
Ben, that's being discussed in a different bughttp://bugzilla.mozilla.org/show_bug.cgi?id=37638
With Accel+L for focus and select contents of URL bar, we musn't forget to make Accel+Shift+L the new hotkey for open location dialog
Summary: RFE Key-combo to move focus to URL Bar (ALT+L/ctrl-space?) (Location bar) → RFE Key-combo to move focus to URL Bar and select contents (Accel+L)
spun off bug 72502 for accel+shift+L.
Depends on: 72502
So in other windows accel+shift+L now opens Open Web Location... and accel+L does nothing?
Status: NEW → ASSIGNED
There's another bug somewhere about having a location bar in Mailnews, it would focus on that. The point of a location bar (with dropdown) in Mailnews is so that you don't have to have so many panes open if you only use a small number of folders.
Looks good, Blake. Although one request I have is, after the document has either started or finished loading, to hide the Navigation toolbar if it was hidden before I pressed Accel+L.
What do others think about Dean's idea? Also, I still need to make the toolbar expand if it's collapsed at the time of trying to show the location bar. Ben's silly toolbar bindings make that harder than it seems.
hokay, accel+L now goes the URLbar and selects its contents [recent linux mozilla build from about 1:30pm today], which is cool. i like Dean's idea, too. but i guess it depends on how difficult it is to implement...
Dean's idea makes sense to me too; as there's little point to moving focus to the URL entry area without making it visible, re-hiding it on use would be consistent with expectations. Testing on WinNT with 2001-04-10-04, accel+L works as expected in every case I tried except one: After switching *to* the Modern theme, accel+L does nothing until focus is placed on the page area or URL entry area by clicking. Guessing that this is a distinct issue, as TAB does nothing either.
No longer blocks: 37587
In Windows, Alt+D is used not only in Internet Explorer, but also in normal folder view.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: --- → mozilla0.9.2
*** Bug 81080 has been marked as a duplicate of this bug. ***
Why is this not marked fixed. Accel+L was chosen for a reason. Alt+letter keys are not used for accelerators in Mozilla. There are many reasons for this. See www.mozilla.org/projects/ui/accessibility/mozkeyintro.html
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Because of what I said in my 4/6 comment.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Blake, can you file a new bug for making sure the location bar is visible after pressing Ctrl+L? This bug is marked as blocking several other bugs, and it would be nice to send 'blocker fixed' spam to those bugs now that Ctrl+L works for normal windows.
filed bug 81331 to cover the toolbar request. re-resolving as fixed.
Status: REOPENED → RESOLVED
Closed: 24 years ago → 24 years ago
Resolution: --- → FIXED
Sounds like Blake still wants to do something on this, based on his 4/6 comment, that isn't quite covered by the new bug.
hm, i thought it did... i guess it isn't as clear to me, at least. anyhow, if another bug needs to be filed, which isn't covered by bug 81331, go ahead... :) but i'm verifying this one.
Status: RESOLVED → VERIFIED
See also bug 157669, add Access+D (Alt+D) for focusing the location bar to match IE and to give users an easier-to-type shortcut.
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.