Next to the back and forward icons on the toolbar are small dropdown buttons that provide a list of 8 sites in the history, in either the back or fwd direction. One option would be to add "Back to" and "Forward to" items to the Go menu, each with the 8-item submenus right there. Or these functions could be combined into one thing in the Go menu, as follows: Back > Google News Alt+Left Slashdot ESPN CNN Forward > Google Local Alt+Right Ars Technica

The Go menu isn't really all that useful at all, yet it doesn't provide access to easiest-to-use history feature we have, which is the dropmarker on the Back toolbarbutton. Any ideas? Submenus don't seem appropriate for the Back and Forward menu items, right?

(In reply to comment #1) > Any ideas? Perhaps a simple modifer to keyboard shortcuts for back/forward, like shift, could be used to invoke the drop-down lists for back and forward? Or using the up/down keys to keep the combinations in the same area? Once invoked, I'd imagine that we'd need to do some work to get keyboard handling for moving up/down through the list ... > Submenus don't seem appropriate for the Back and Forward menu items, right? Definitely not. Seems like a whole bunch of overkill.

Personally I think the problem is that the Go menu itself is where this functionality should be, but it is not a well-thought through menu. The stuff that's in there is for all the tabs, not just the current one, and there is no way to see where your current page is within the current set of items.

CC'ing Mike he apparently missed my last response, comment #3

Workaround to use go menu. Not ideal, but let's not mark this sec508.

*** Bug 321080 has been marked as a duplicate of this bug. ***

I strongly feel that the best solution for this would be to return the Go menu to its original longstanding Mozilla Suite / Netscape Navigator functionality. I have always found IE's method of navigating backwards and forwards in the current window's browsing "stack" unintuitive and hard to use. Always greatly preferred Netscape/Mozilla's Go menu. With the Go menu you can see at a single glance where the page you're looking at fits into the history stack, and you can make repeated arbitrary navigations forward and backward without having to first think about which of the left and right arrows' pulldown menus to activate. With the arrow menus, you have to mentally compare the contents of one of the menus with the other to envision the browsing stack, and think about what being farther down in the menu means in the left arrow menu vs. the right arrow menu (in one, newer pages are higher up, while in the other, newer windows are lower down). Also, the little pulldown menu arrows are a much trickier target to hit quickly with the mouse than the well-spaced Go menu heading. Speaking of the mouse, if you use extra buttons on it for Back and Forward, you can remove the Back and Forward onscreen buttons to make more room for the URL bar, but only if the traditional Mozilla Go menu functionality is there. Unfortunately in Firefox the extremely useful traditional functionality of the Go menu was removed. In its place, a list of recently visited pages was unintuitively substituted. I know that many people besides me find this list of recent pages useless, as there are multiple Firefox extensions that cause the Go menu to not appear (of course some people do this because it causes huge delays if you don't restrict yourself to a very short History lifetime -- see bug 222717). Unfortunately there aren't any extensions to bring back the old Go menu functionality, rather than removing it altogether, so my only hope is for this to be implemented in the browser itself, either unconditionally or under control of a preference. And as suggested, this is very important for accessibility reasons. Multi-hop backwards or forwards navigation was certainly much easier for keyboard users when it just meant Alt, a letter, and then a few successive presses of the Down arrow key. Bug 169346 is marked as FIXED, but it is _not_, since that commenter's accessibility issue was not addressed by the implementation of a Go menu with a semi-random list of recent pages, rather than the current window/tab's history stack. I guess the only suggestion I'd make for an improvement to the traditional Go menu functionality would be to make it so that if your browsing stack is so long it doesn't fit in the menu, to make it so that going back (or forward) in the stack via the Go menu as far as you can would cause the menu to be recentered there, so you could then go back several more steps. As traditionally implemented, you'd have to go back as far as you could, then click on any random link in the window (erasing your forward history), and then that would "recenter" the menu and you'd have the opportunity to continue going back farther.

I want to take a completely different approach towards solving this bug. Currently we're stuck on improving the Go menu, which is a good discussion to have, but I believe that discussion should take place in another bug. The original point of this bug was that toolbar buttons are not keyboard accessible. Rather than discuss how to duplicate the functionality of the toolbar buttons elsewhere, I propose we make toolbars and toolbar buttons keyboard-navigable. This problem is not simply about Firefox's built-in toolbar. It affects third-party toolbars as well, and yes, I've fielded questions from companies that want to create accessible Firefox toolbars. I've done some preliminary research in this area. There are several applications on different platforms that make their toolbars fully or partially keyboard-accessible, and many that ignore the problem as Firefox currently does. Rebar control (standard Microsoft container for creating rich toolbars): - no MSAA support at all, not keyboard navigable Acrobat Reader (Windows version): - does not support tabbing to toolbar - however, if you click a toolbar button, you can then tab/shift-tab to all other toolbar buttons Eclipse (Windows and Linux): - toolbars are in the normal tab order - tabbing to a toolbar focuses the first focusable element within the toolbar - once inside toolbar, left/right arrow keys move between buttons - right arrow on the last button wraps around to the first button - once focused on a button, space or Enter activates the button - if the toolbar button has a dropdown menu, down arrow key opens the menu, then Esc closes the menu - if the toolbar has separators, arrows only move between buttons within the same group; tab moves to the next group beyond the separator GIMP (Windows and Linux): - toolbar buttons in tools palette are all focusable, in normal tab order - tab moves to next toolbar button - not necessarily a fair analogy, since the tools palette is in a separate window Microsoft Windows Defender (Windows-only): - toolbar buttons are focusable, in normal tab order - tab moves to next toolbar button, then down to other controls in the window, then back to the first toolbar button (i.e. the toolbar buttons are treated as any other control in the window) - combination button+dropdown controls are exposed as two controls (tab once to the button, tab again to the dropdown triangle) Evolution (Linux): - similar to Eclipse (but different) - Tab takes you to the toolbar grippy, pressing space on this grippy maximizes the toolbar - Tab again takes you to the first focusable button on the toolbar - Once on an focusable toolbar button, left/right arrow keys move between other toolbar buttons, but *without* wrapping from the last button back to the first one - Tab again takes you off the toolbar - There is some weirdness though. The toolbar consists of [Grippy, New, Send/Receive, Reply, Reply All, Forward, Move, other]. New and Other have dropdown menus. New is not keyboard-accessible at all; both tab and arrow keys skip over it. But the Other dropdown menu *is* keyboard-accessible; you can right-right-right arrow to get to it and then open with menu with space. - Other weirdness: down arrow takes you off the toolbar, to the nearest focusable element below the currently focusable element. OpenOffice.org (Windows version): - inconsistently semi-accessible - once a toolbar button/field receives focus, you can use either left/right arrows or tab/shift-tab to move between other elements on the same toolbar - no way to move off the toolbar once you're on it - no way to move to other toolbars Opera (Windows version): - no keyboard accessibility for toolbars IE 6: - no keyboard accessibility for toolbars There is no particular standard behavior that I can find. Many applications match Firefox's current behavior of ignoring toolbar keyboard accessibility altogether. Others (including the latest version of the most recent application released by Microsoft) treat toolbar buttons as equals to all other window controls. Others (Eclipse, Evolution) treat the toolbar as a grouping container like a radio group -- tab to the toolbar, then arrow around within it. I also want to head off a concern I've heard in IRC from mconnor and others, that putting the toolbar in the tab order makes keyboard navigation more difficult, e.g. tabbing from the urlbar to the web content area. This problem is already solved by other global keyboard shortcuts: F6 already cycles between urlbar and web content, skipping over all focusable elements in between (including web search box and, if I had my way, focusable toolbars). I don't buy the concern that adding elements to the chrome tab order screws up "muscle memory" or whatever phrase people use to describe keyboard users on auto-pilot. Such users should learn the existing shortcuts that actually do what they want (get to the web content area, or back); this should not be an excuse to avoid ever adding focusable elements to the tab order.

Further investigation into xul:toolbarbutton reveals that adding a class="tabbable" puts the toolbarbutton in the normal tab order. (The Print Preview toolbar currently does this, but nothing else seems to.) I had to add some keyboard handlers to toolbarbutton.xml#menu-button so that space or Enter activates the button itself. Everything else Just Works -- while the back/forward button has focus, F4 opens the dropdown history menu; arrow keys navigate the dropdown menu; Esc closes the dropdown menu; Enter activates the selected dropdown menu item.

I'm updating the status whiteboard field so I can run an intenral report. Don't interpret this as impatience; I know things are crazy right now.

(In reply to comment #8) As I read it, Microsoft's HIG implies that toolbar buttons shouldn't be tabbable: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwue/html/ch08a.asp Most of the Windows application you cite seem to respect that and so should (IMHO) Firefox. That might already be reason enough for a WONTFIX. Furthermore it won't be obvious how to get to those two buttons (probably Ctrl+L, Shift+Tab for Forward and a second Shift+Tab for Back) and the two drop-downs will thus not be as easily discoverable for keyboard users as a revamped Go/History menu (where this - as already mentioned - rather belongs). Finally, this might give extension authors a bad precedent and you might soon see the tabbing sequence to get to the tabbar (currently Ctrl+K, Tab) affected by other toolbars/menu buttons.

*** Bug 187204 has been marked as a duplicate of this bug. ***

It strikes me that: - we have keyboard shortcuts for "Forward" and "Back" - what we're talking about it being able to get to the drop-down lists for those shortcuts So why don't we do something where shift-modifying the existing shortcuts pops up the drop down menu with focus to react to keyboard events?

I like that alright, but it's not as good as something discoverable. However, if we can't think of a nice way to do that without creating unwanted interface clutter, I can live with the tradeoff. What's your thought on that?

So, has any of the other major browsers (IE7, Safari 2/3, Opera 9) come up with a better solution in the meantime? Another suggestion: unifying Back and Forward buttons (bug 386228) would result in a single popup which could quite easily be added to the History menu (e.g. above Recently Closed Tabs) and would result in only minimal UI impact while remaining quite obvious to discover.

IE7 puts the toolbar in the tab order. Up and down arrows cycle through the buttons. I think for logic and consistency's sake, we ought to make the toolbar tab focusable. I think the toolbars belong in the tab order immediately following the list of open browser tabs. Left and right arrows would cycle through the buttons, just as they do through the browser tabs. Down arrow would open popup lists. Space bar or enter would activate them. What were the problems people had doing things this way, aside from the clutter? F6 is a standard windows key to jump between different areas of an application, so if someone was frustrated that they were stuck in the location/search/toolbar area, f6 would cross their mind as a way to get to the main browser area.

Interestingly enough, the Back/Forward button is the only one you _can't_ tab to in IE7. The main reason they have to make things tabbable is that they try to get along without a menu, though (Opera and Safari seem to not even let you tab to the address bar - and F6 doesn't work for either of them). If all functionality from the toolbar is easily obtained from the main menus, there's not much to be gained by adding more tab stops, is there? Might seem like an overly general solution for a quite specific problem. OTOH it would still be interesting to try this out. Potential issue: we'd have to somehow group buttons together for arrowing, as when you arrow into the address/search bar, you'd have to use the tab key for getting out again. Furthermore I'd rather keep the tab order left-to-right/downwards, so that the main toolbar buttons come before the address/search/tab bars (which would even keep things as-is for people Ctrl+L'ing and then tabbing onwards).

My reason for suggesting the toolbars go last is that most of the buttons apply to the current tab. The fact that the location bar is before the list of browser tabs throws me for a loop too, but that's a different story. You're right in that it's not necessary to do all this just for the back/forward dropdowns, but it's becoming good practice to have a tab order that gets to all menaingful parts of the program. This will probably become even more important as the new UI changes are checked into the trunk. There's talk about, among other things, minimizing the download manager to the status bar. If this ends up happening, keyboard users are going to need a way to get to it.

Please just don't confuse tabbing with proper keyboard accessibility (just unplug the mouse for a day or two to see the difference ;-) ).

(In reply to comment #19) > (just unplug the mouse for a day or two to see the difference ;-) ). Alright, you know the difference. In that case, either extending accessibility.tabfocus or adding a new pref specifically for (browser-)chrome might be the way - so that you can configure whether toolbars and statusbar should become tabbable.

Simon, if we're going to touch this part of the UI and make it even more useful (bug 386228) then let's please take the opportunity to make it accessible and section 508 compliant as well.

Gah, it's not fixed.

As outlined in comment #15, the plan would be to add a new "Tab History" submenu to the History menu and expose the content of the unified back/forward popup there. Not sure whether that's still feasible, though, as IIRC we're already past string freeze. Nonetheless, should we still have a chance for fixing this: Please suggest a name/label for this new submenu and its placement. History -> "Tab History" sounds somewhat repetitive; and placing it above the Recently Closed Tabs submenu might make it harder to find than e.g. placing it below Back/Forward.

Simon, my first suggestion would be to replace the current list of items in the History submenu, between Home and Recently Closed Tabs, because yet another list would just be confusing. It's never been clear to me what the difference is between that list and what you get from the toolbar sumbmenus. If it's not clear to me who works on Firefox all day long, then it won't be clear to our users either. If there's really a significant reason to have two separate lists and it needs to be a sub-sub menu, then I guess I'd need to know what the difference between the two lists is in order to recommend a name. I find the new combined list for the toolbar, with the current page checked, much more useful than what's in the history menu. I never use the History menu. Does anyone?

So, what's the difference between those 2 history lists?

(In reply to comment #25) The History menu lists the top 15ish items from the History sidebar when ordered "by last visited" state. I guess the advantage is that this list is global (as is the menu) while the back/forward drop-downs are local to the selected tab. OTOH there seems to already have been the intention to indeed unify those two lists (cf. bug 329183). I'd be all for it, don't know about the Mikes though.

I've got no cycles left for this.

(In reply to comment #28) Won't this break in the case where the location bar lies before the dropmarker in the tab-order (e.g. when the navigation buttons are to its right)?

(In reply to comment #29) > (In reply to comment #28) > Won't this break in the case where the location bar lies before the dropmarker > in the tab-order (e.g. when the navigation buttons are to its right)? Yes, that's one of the cases where the dropmarker will still not be reachable. That's however better than the current situation.

Please hold off on reviewing this patch for a bit! Aaron and I were just discussing an idea for a different approach to this problem. However, I'd like to discuss this with faaborg first before we proceed. I've tried the patch, and while it works technically, the tab order is slowly feeling like the one in IE 7, and that's something I would not appreciate in Firefox. :-)

I like this approach much better. The remaining question is whether we should get rid of the original History menu items below "Show All History", and fold the back and forward menu into that menu instead. Does anyone actually find the old menu items in the History menu, that point to *any* recently visited page, regarrdless of session or tab, useful at all? But if it is decided to keep the old-style History menu items, too, I'd be fine with the Back and Forward items being on the sub menu.

(In reply to comment #34) > The remaining question is whether we should > get rid of the original History menu items below "Show All History" New bug, please.

Comment on attachment 301073 [details] [diff] [review] add menu to the menubar I'd almost rather have the design posited in comment 0 than this one. The individual back and forward items are important and shouldn't be removed.

This does not block the final release of Firefox 3.

(In reply to comment #36) > I'd almost rather have the design posited in comment 0 than this one. This would add more overhead, since we're only building one menu type right now, the unified one. I wonder why we changed our old menus to a unified one in the main nav toolbar if you prefer the design in comment 0. > The individual back and forward items are important Actually, they have direct shortcuts, which makes them much less important as individual menu items. The deep list, on the other hand, is not accessible at all, which is why this should block the final release of Firefox 3.

Renominating this one for blocking. I still think that Dão's last approach was the best alternative. Having this at the top of the top of the History menu would be preferable.

This will not block the final release of Firefox 3. Any patch will need unit tests in order to be approved.

Unit tests don't make any sense for this bug. What this bug needs is ui-review.

Why don't unit tests make sense for this bug? http://quotes.burntelectrons.org/3600

We could test if the menu is there. We could probably test if there are access keys. Sounds boring and useless, though, and we usually don't do this for menus. Lower-level session history tests for would make more sense, but that's hardly related to this bug.

Have Firefox 3.03 and sp3. "Problems while using Firefox" No movement forwards or back is available. The logo for it < > is just gray and nothing happens. At the same time I have a history thats stuck- (cant delete- and i dos not change at all). Tryed getting rid of private informations-and reloading Firefox..Dosn`t change anything. It gets tiresom to start op program ever so often

Is anyone still following??? I want to take it on, but I could need a little introduction. So much has changed. All of the above wasn't any helpful to me. If it is due to my lacking knowledge, instruct me. My suggestion right now would be to bind a keyboard shortcut to the tab's history.

Please assign me! I have a solution. It's basic, but 100% functional

this patch grants access to the tab's backForwardHistoryContextMenu via a key combination. i chose accel + e, because I didn't come across a mapping for this combination. suggestions are welcome, of course. the positioning of the window isn't optimal yet. so this is all but a final version of this patch.

(In reply to marvelous82 from comment #47) > i chose accel + e, because I didn't come across a mapping for this > combination. suggestions are welcome, of course. accel+e focuses the search bar...

right. i only noticed that now. it didn't seem to make any trouble, though. i never had a clinch between those two. my submenu always responded, never the search bar. So what to do? Either move my key (only found q & y to be left in conjunction with accel); add shift; use alt; take accel + e away from search bar, since it has accel + k. anytihng else?

The search bar should keep accel+e, that's for parity with Internet Explorer.

:p IE... alright. ctrl + shift + e wouldn't make sense either, if that's the case, would it? i read, that alt should be avoided as a modifier. accel + y ?

I have a few suggestions for the keyboard shortcut that might be more discoverable and memorable: hold down Alt + ← (or →). Normally, when you click on the Back (or Forward) button once, you move back one page; if you click-and-hold, on the other hand, you get the menu with the tab’s history. Since we already have a keyboard shortcut that works just like clicking on the button once, why not extend its behaviour to work with click-and-hold, just like the graphical button? So, thus: Alt + ← (and ← released): Back Alt + ← (and held, without releasing): Back/Forward history menu appears, with the most recent page highlighted. At that point, you can release the ← key and use the arrow keys to select a page in the history. There are several advantages to this behaviour. First, there’s no need for yet _another_ keyboard shortcut. Second, this shortcut is more discoverable to its target audience, and people who are already used to using Alt + ← to go back might accidentally discover this functionality by hesitating when releasing the ← key. By the way, the current behaviour is kind of weird (and possibly a bug). If you click-and-hold Alt + ←, the page title changes to the previous page, as if that page is loading, while the page doesn’t change at all. When you release the ← key, the next page in the Back history is actually loaded. I’m not sure if that’s intentional, but I think my suggestion makes much more sense. ____ An alternative suggestion: Alt + ↓ (or ↑) immediately brings up the Back/Forward menu, selecting the previous (or next) page. You can move up and down the list as long as you hold Alt. When you release Alt, that page is opened. Esc while holding Alt removes the menu. Currently this keyboard shortcut is used only while you’re in the Search bar, so it’s unused when you’re likely to need it. Although it adds another new shortcut, it’s faster than the previous suggestion. ____ One final alternative is the last suggestion, but with ← (or →) instead. In other words, change the current shortcut’s behaviour to show the menu instead. In practice, the big difference is that you have to release Alt first for the page to change. But you gain the discoverability of this functionality for everyone who uses the current keyboard.

(In reply to marvelous82 from comment #51) > alright. ctrl + shift + e wouldn't make sense either, if that's the case, > would it? Already taken: http://mxr.mozilla.org/mozilla-central/search?string=tabView.commandkey > accel + y ? Also taken: http://mxr.mozilla.org/mozilla-central/search?string=redoCmd.key

well, that clears that. i'm still really new. so forgive me for not having looked up everything properly. i took this page as reference: http://support.mozilla.org/en-US/kb/keyboard-shortcuts-perform-firefox-tasks-quickly my search returned this: http://mxr.mozilla.org/mozilla-central/search?string=%22q%22&find=browser/base/content can i assume, that accel + q would be acceptable as interim solution? this way we have no collision for now. i like your suggestion David. Especially the 1st one. but i can't estimate, how much time i would need for that. hints are appreciated. would that be an event handler for a key or something like that?

(In reply to marvelous82 from comment #54) > i like your suggestion David. Especially the 1st one. but i can't estimate, > how much time i would need for that. hints are appreciated. would that be an > event handler for a key or something like that? Thanks! I’m not a programmer, so I have no idea how to make that work. I would just say that you probably want to make the click-and-hold time the same as that for the graphical button. Perhaps someone else could answer your other question.

I completed the function. I'm changing the status to resolved - worksforme.

(In reply to marvelous82 from comment #57) > I completed the function. What does this mean? > I'm changing the status to resolved - worksforme. This is still an issue as far as I can tell.

How can UX help? Why is this bug uiwanted? What is the ui question to answer?

(In reply to Markus Jaritz [:maritz] (UX) from comment #59) > How can UX help? Why is this bug uiwanted? What is the ui question to answer? Can you propose a way how we can make the back / forward menus keyboard accessible, e.g. by having them somewhere in the menu bar?

(In reply to Dão Gottwald [:dao] from comment #60) > Can you propose a way how we can make the back / forward menus keyboard > accessible, e.g. by having them somewhere in the menu bar? I can not recommend using the menu bar as the only entry under which it might fit is History, which is a global, and not a tab-specific history. We should use a shortcut to open the menu. David Regev made 2 very smart suggestions. His first of mirroring the graphical behavior might help people that currently use the feature with the mouse, but would prefer to use a shortcut. Great idea! I would recommend implementing it. His second suggestion would eliminate the time delay, but differ from the one-step interaction. Could be implemented in addition if demand on getting rid of the short time delay is high. His third idea might be the most complex and extend the effort for a single back as there is no immediate feedback in clicking the arrow-key, and a menu pops up instead of seeing the old page. I would not recommend implementing that. (In reply to David Regev from comment #52) > I have a few suggestions for the keyboard shortcut that might be more > discoverable and memorable: hold down Alt + ← (or →). > > Normally, when you click on the Back (or Forward) button once, you move back > one page; if you click-and-hold, on the other hand, you get the menu with > the tab’s history. Since we already have a keyboard shortcut that works just > like clicking on the button once, why not extend its behaviour to work with > click-and-hold, just like the graphical button? > > So, thus: > > Alt + ← (and ← released): Back > Alt + ← (and held, without releasing): Back/Forward history menu > appears, with the most recent page highlighted. At that point, you can > release the ← key and use the arrow keys to select a page in the history. > > There are several advantages to this behaviour. First, there’s no need for > yet _another_ keyboard shortcut. Second, this shortcut is more discoverable > to its target audience, and people who are already used to using Alt + ← to > go back might accidentally discover this functionality by hesitating when > releasing the ← key. > > By the way, the current behaviour is kind of weird (and possibly a bug). If > you click-and-hold Alt + ←, the page title changes to the previous page, as > if that page is loading, while the page doesn’t change at all. When you > release the ← key, the next page in the Back history is actually loaded. I’m > not sure if that’s intentional, but I think my suggestion makes much more > sense. > > ____ > An alternative suggestion: Alt + ↓ (or ↑) immediately brings up the > Back/Forward menu, selecting the previous (or next) page. You can move up > and down the list as long as you hold Alt. When you release Alt, that page > is opened. Esc while holding Alt removes the menu. > > Currently this keyboard shortcut is used only while you’re in the Search > bar, so it’s unused when you’re likely to need it. Although it adds another > new shortcut, it’s faster than the previous suggestion. > > ____ > One final alternative is the last suggestion, but with ← (or →) instead. In > other words, change the current shortcut’s behaviour to show the menu > instead. In practice, the big difference is that you have to release Alt > first for the page to change. But you gain the discoverability of this > functionality for everyone who uses the current keyboard.

(In reply to Markus Jaritz [:maritz] (UX) from comment #61) > David Regev made 2 very smart suggestions. His first of mirroring the > graphical behavior might help people that currently use the feature with the > mouse, but would prefer to use a shortcut. Great idea! I would recommend > implementing it. Thanks for the compliment, Markus! I had totally forgotten about my suggestions. Thinking about it again, I now prefer my third suggestion. Since I didn’t explain that one in detail before, I will do so here (with slight modifications): 1. Hold Alt and press ← (possibly releasing ←). 2. The Back/Forward menu shows, with the previous page highlighted. 3. At this point, you can use any of the arrow keys to navigate between the choices. 4. Release Alt. 5. The tab navigates to the chosen page. (Of course, using → instead would be identical, but with the next page instead.) I prefer this approach over the the first one because press-and-hold is quite undiscoverable, and even more so on keyboards, where this approach is generally not used. Also, the and-hold part is pretty annoying, unless the delay is quite short. > His third idea might be the most complex and extend the effort for a single > back as there is no immediate feedback in clicking the arrow-key, and a menu > pops up instead of seeing the old page. I would not recommend implementing > that. You make a good point. The way the Alt shortcut is used would be changed slightly, as you now have to release Alt. However, since you have to release the key anyway, it wouldn’t really add any time to this interaction, once you get used to it. As for the immediate feedback issue, the new feedback would be the B/F menu popping up immediately. It might take a moment for a user to figure out what has happened, but I think this would be much more discoverable than suggestion #1. In any case, either of these suggestions being implemented would be great!

(In reply to Markus Jaritz [:maritz] (UX) from comment #61) > His third idea might be the most complex and extend the effort for a single > back as there is no immediate feedback in clicking the arrow-key, and a menu > pops up instead of seeing the old page. I would not recommend implementing > that. Thinking about it some more, I just realized that there’s an even better solution, one that avoids the issue of the page not changing immediately: show the menu *and* display the previous page. Let’s call this solution #4: 1. Hold Alt and press ←. 2a. The page immediately changes to the previous page, while… 2b. The Back/Forward menu appears, highlighting the (new) current page. 3. At this point, you can continue to use any of the arrow keys to navigate between the choices. As soon as an arrow key is pressed, step 2 is repeated: the page behind the menu changes in the background, while the menu items scroll up or down, reflecting the new current page. 4. Release Alt. 5. The menu disappears (and the desired page has already been loaded). The nice advantage of this approach is that you immediately see the page that you’ve selected. Also, instead of replacing the current functionality, it extends in a nice way. Engineering-wise, however, this would be more difficult to implement, since the multiple page loads must not interfere with the interaction and the menu display. For example, it should be possible to hit ← four times quickly and have the browser start loading the right page immediately. I hope that was clear. Markus, what do you think?

(In reply to David Regev from comment #63) > Thinking about it some more, I just realized that there’s an even better > solution, one that avoids the issue of the page not changing immediately: > show the menu *and* display the previous page. Let’s call this solution #4: > > 1. Hold Alt and press ←. > 2a. The page immediately changes to the previous page, while… > 2b. The Back/Forward menu appears, highlighting the (new) current page. > 3. At this point, you can continue to use any of the arrow keys to navigate > between the choices. As soon as an arrow key is pressed, step 2 is repeated: > the page behind the menu changes in the background, while the menu items > scroll up or down, reflecting the new current page. > 4. Release Alt. > 5. The menu disappears (and the desired page has already been loaded). > > The nice advantage of this approach is that you immediately see the page > that you’ve selected. Also, instead of replacing the current functionality, > it extends in a nice way. Engineering-wise, however, this would be more > difficult to implement, since the multiple page loads must not interfere > with the interaction and the menu display. For example, it should be > possible to hit ← four times quickly and have the browser start loading the > right page immediately. > > I hope that was clear. Markus, what do you think? Very good combination of steps David. In writing this sounds very good. One can still use the shortcut as learned, see the menu appear and thus learn how jumping multiple pages works, and have immediate feedback. I would love to see that in action. So far my only concern is that having the menu appear every time might annoy some users, but then again, if you quickly release both keys, you probably wouldn't even see it. Would be great to be able to test your solution 4!

I don't think it would be a good idea to have the page immediately change as you navigate back and forth through the history. That would slow down things quite a bit, especially on slower machines, or if you needed to move back many pages through the history. Also, there are some times where you have to skip over a particular page in the history and go directly to one before it, as the interim page has side effects if viewed, or immediately redirects to another page, etc. I think suggestion #3 is the best approach.

(In reply to Dan Harkless from comment #65) > I think suggestion #3 is the best approach. I would be fine with that too. Suggestion #3 (comment 62) would also be more consistent with the way the back/forward menu works graphically, in that the page doesn’t change until you’ve actually clicked on your selection. (That said, it would be great if some sort of preview were shown before selecting a page in the menu, whether graphically or via the keyboard.)

Any chance to get a keyboard shortcut (Alt+Down for example) to open the session history dropdown? No extra functionality, just the same thing as a right click on the button. I didn't read the whole thing above, and it's probably irrelevant by now. The title is spot on though - 13 years later, Firefox "back" and "forward" toolbar submenus are still not keyboard accessible. Before Quantum era, I had keyconfig extension do that for me.