Closed Bug 19446 Opened 25 years ago Closed 23 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: 23 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: 23 years ago → 23 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.