Last Comment Bug 102909 - No keyboard access to link toolbar
: No keyboard access to link toolbar
Status: NEW
: access, testcase
Product: SeaMonkey
Classification: Client Software
Component: UI Design (show other bugs)
: Trunk
: All All
-- enhancement with 6 votes (vote)
: ---
Assigned To: jag (Peter Annema)
: 123353 132607 141989 150629 160217 183182 240707 (view as bug list)
Depends on: 241105
Blocks: 103053
  Show dependency treegraph
Reported: 2001-10-03 09:58 PDT by Hixie (not reading bugmail)
Modified: 2012-08-21 23:43 PDT (History)
27 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---


Description User image Hixie (not reading bugmail) 2001-10-03 09:58:28 PDT
   Disconnect your mouse.
   Open the link toolbar if required (Alt+V, W, down, down, enter).
   Go to a web page with link elements (Ctrl+L and type URI), e.g.:
   Use one of the links on the link toolbar.

   You can't.

   There should be a menu somewhere giving you access to the menu items 
   equivalent to a menu-ized link toolbar (this could go, e.g., in the Go menu).

cc'ing usual suspects as per bug 102832.

mpt: could you give us some UI advice here? Which menu is appropriate?
Comment 1 User image Hixie (not reading bugmail) 2001-10-03 10:21:35 PDT
Sorry, the link in the initial description should be
Comment 2 User image Gervase Markham [:gerv] 2001-10-03 11:11:13 PDT
This is an RFE, even if it is an accessibility issue. The problem is that most
solutions would be fairly deeply nested. But I'd go for Go | Related Document or

Comment 3 User image Jesse Ruderman 2001-10-03 12:39:57 PDT
See also bug 33684, which includes Alt+up for going up a direcotry, even if the 
page doesn't have a <link> element saying where "up" is.
Comment 4 User image Mike Young 2001-10-03 18:26:03 PDT
As was mentioned in bug 2800 when the Link toolbar was under discussion, the
features of the Link toolbar should be placed in the Go Menu. There should be a
seperator and sub menus as appropriate. (From what I understand they will not
exceed 3 levels)

The Up choice in that menu will be filled with a truncated URL if no "Up" Link
is specified. (That's what bug 33684 is for.)
Comment 5 User image Matthew Paul Thomas 2001-10-05 18:14:54 PDT
> mpt: could you give us some UI advice here?

The links in the Links Bar should be part of the Tab/Shift+Tab cycle, just like
the rest of the links in the page or frame.

> Which menu is appropriate?

None. We don't list A HREF links in a separate menu, either.

> (From what I understand they will not exceed 3 levels)

Submenus should never exceed one level.
Comment 6 User image Hixie (not reading bugmail) 2001-10-06 16:40:46 PDT
The link toolbar being part of tab/shift+tab would work for me.
Comment 7 User image Tim 'Tool-Man' Taylor 2001-10-13 10:23:47 PDT
bug 104586 would provide an alternate way to satisfy this bug by making all the
LINKs available in the toolbar also accessible from the main menu system.  This
is consistent with how functionality in all other toolbars is given keyboard
access.  I prefer it to making a toolbar part of the TAB cycle.
Comment 8 User image Ben Bucksch (:BenB) 2001-11-09 21:34:08 PST
> The links in the Links Bar should be part of the Tab/Shift+Tab cycle, just like
> the rest of the links in the page or frame.

I disagree. This cycle is unsably long enough already, no need to entend it further.
IMO, the link toolbar is UI, not part of the page.

I vote for a common modifier key plus
cursor left:   Next
cursor right:  Prev
cursor up:     Up
cursor down:   first child (chapter, section, subsection or rev-parent)
home:          either Top or First
end:           Last, if home = First
Comment 9 User image Matthew Paul Thomas 2001-12-13 21:25:26 PST
Certainly, if Beonex could follow Microsoft's lead and convince the world's 
keyboard manufacturers to add a new modifier key to their keyboards, and then 
persuade everyone to upgrade to such keyboards just for use with Mozilla, 
direct keyboard shortcuts would be an option. However, that might take a while.
Comment 10 User image Hixie (not reading bugmail) 2002-01-09 18:38:26 PST
Changing summary to reflect the only workable proposed solution.
Comment 11 User image Ben Bucksch (:BenB) 2002-01-10 04:54:51 PST
I disagree. There would be no point in doing that.

Since not all browser support link toolbars, we can assume that the pages will
have the same functionality accessible via normal links. These links are in the
tab-cycle of the page anyways, so the functionality is already available via
this means. The only thing you would achieve is that you have Next *twice* in
the tab-cycle - once as normal link and once as link toolbar button.

The main advantage of the link toolbar is that it offers a well-known location,
which I can hit without looking at the page (so I can e.g. hit Next 3 times in a
row). The keyboard equivalent of this would be to have fixed hotkeys for the
link toobar buttons.

I don't know by what all my proposed keys are already occupied, but we should be
able to find *some* free hotkeys which we can use for this. Say, Ctrl-D for
Previous, Ctrl-G for Next, Ctrl-R for Up, Ctrl-E for Top. This was only an
example - well possible that some of these are already taken, but again, there
should be *any* set of hotkeys which is still free. If not, maybe make room by
removing some obsure ones.
Comment 12 User image Ben Bucksch (:BenB) 2002-01-10 04:59:38 PST
I forgot: For the less used options on the Link toobar, esp. those in the menus,
we could use a method similar to the main menu: Have a hotkey which focuses the
link toolbar and thus allows the user to navigate in it and activate options
there this way (via Tab, normal cursor keys, return etc.).
Comment 13 User image Boris Zbarsky [:bz] (still a bit busy) 2002-02-04 10:02:47 PST
*** Bug 123353 has been marked as a duplicate of this bug. ***
Comment 14 User image t.schnier 2002-02-05 02:00:25 PST
I would argue that at least 'previous' and 'next' are assigned some _very_ easy
to find keys. 

I use mozilla for classroom presentations (instead of powerpoint), so going to
the next and previous slide should be as simple as possible. 'Backspace' (for
back) is still available as far as I can see. 'Space' is already used, but maybe
if the page has already scrolled to the bottom (or the whole page is displayed),
'space' could trigger the next page ? This is what some newsreaders do... 

Comment 15 User image Matthew Paul Thomas 2002-04-17 22:19:50 PDT
t.schnier, that's bug 59118.

I find it slightly amusing that *every one* of Ben Bucksch's proposed keyboard 
shortcuts is already taken by a more common function. We just don't have spare 
keys. Putting REL/REV links in the Tab cycle is still the only viable option.
Comment 16 User image Jesse Ruderman 2002-04-19 05:34:13 PDT
*** Bug 132607 has been marked as a duplicate of this bug. ***
Comment 17 User image Jesse Ruderman 2002-04-19 05:45:17 PDT
Suggestions from bug 33684 (infer up from URL) and bug 32627 (infer next/prev) :
Alt+-        Prev (since Prev usually goes to the previous /numbered/ something)
Alt++        Next 
Alt+Shift+-  First
Alt+Shift++  Last
Alt+Up       Up
Alt+/        Top (not alt+shift+up to avoid conflicts with directional navigation)

I agree with BenB that it doesn't make sense to include these links in the tab
Comment 18 User image Hixie (not reading bugmail) 2002-04-19 06:38:36 PDT
directional navigation?
Comment 19 User image Robert Wall 2002-05-03 06:59:26 PDT
*** Bug 141989 has been marked as a duplicate of this bug. ***
Comment 20 User image Jesse Ruderman 2002-05-06 16:14:19 PDT
Directional navigation is like tabbing but depends on where focusable objects
appear on the screen rather than their order in the HTML.  The Windows desktop
uses directional navigation instead of tab navigation.  It would probably be
alt+shift+arrow or ctrl+arrow if Mozilla had it (bug 67684).
Comment 21 User image Jesse Ruderman 2002-06-10 14:58:45 PDT
*** Bug 150629 has been marked as a duplicate of this bug. ***
Comment 22 User image Daniel Wang 2002-07-30 17:30:37 PDT
*** Bug 160217 has been marked as a duplicate of this bug. ***
Comment 23 User image Jessie Li 2002-12-03 21:12:50 PST
Since the bug 134823: Toolbars don't honour accesskeys
has been fixed, we can implement this by adding accesskeys to the links in
linktoolbar,such as:
Comment 24 User image Jessie Li 2002-12-03 21:13:53 PST
*** Bug 183182 has been marked as a duplicate of this bug. ***
Comment 25 User image robbe 2002-12-05 00:26:07 PST
While Modifier + Character shortcuts are fine as a fallback, I'd very much
prefer Modifier + Special Key. The downside of N for Next is that in localised
versions it either becomes illogical, or a completely different shortcut. If my
muscle memory still largly works on a French Mozilla, that's a good thing.

My humble suggestions (all keys seem to do nothing in my copy):
Mod-PgUp        Previous
Mod-PgDn        Next
Mod-Home        First
Mod-End         Last
Mod-Shift-PgUp  Up
Mod-Shift-Home  Top
Comment 26 User image Hixie (not reading bugmail) 2002-12-05 11:10:12 PST
Ctrl+PgUp/PgDn = navigating tabs
Alt+PgUp/PGDn = navigating sidebars
Ctrl+Home = Go to top of document in caret mode
Alt+Home = Go to home page
Ctrl+End = Go to bottom of document in caret mode

Look on the keyboard binding chart, though, there might be some free keys about
if we use the Mod+Shift combinations.
Comment 27 User image timeless 2002-12-05 11:27:09 PST
shift+mod is often used by the os, window managers and third party macros.
when it isn't, it's used for selection.

While it wouldn't be as convenient i'd prefer to be able to walk the toolbar.

If you don't care about caret browsing and if you don't care about selection
browsing (which i had never met until today) then we could just use:
shift-arrows and ctrl-shift-arrows, which only runs into problems w/ windowmanagers.

why not do what everyone else does and abuse the context menu ;-).

but seriously why not put this stuff into the go menu?

  {global list of recent pages}
 lOcation [hypothetical movement from file>open location, or a way to get to the
location bar]
Comment 28 User image uamjet602 2003-01-06 08:13:54 PST
Even if you cannot come up with keys that are free to be used for the link
toolbar, please consider letting me choose keys for myself.

I don't know if there already is a way to configure these keys though.

If there isn't, my suggestion would be <accel>+, and <accel>+. (as these are the
< and > keys.) One could also consider [ and ] but ctrl-[ typically is escape.
Comment 29 User image Jesiah S 2004-05-19 14:00:46 PDT
*** Bug 240707 has been marked as a duplicate of this bug. ***
Comment 30 User image Chris "SoopahMan" Moschini 2004-05-19 18:56:00 PDT
I agree with tinus_mozilla.

One possibility until hotkeys are configurable is to make it the numpad keys -
the keys actually lend themselves well to the common link types:

Up key - Up
Left key - Prev
Right key - Next
Comment 31 User image Robert Kaiser 2009-06-14 07:39:35 PDT
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Comment 32 User image Kalle Valo 2010-01-30 00:03:12 PST
*** This bug has been confirmed by popular vote. ***

Note You need to log in before you can comment on or make changes to this bug.