Browser toolbars typically offer "back", "forward", "reload", and "home". Of these, "reload" and "forward" are probably rarely used. If you use tabs heavily, you may not use "back" much anymore, but personally I only make use of tabs in a limited fashion, and I rely heavily on the browser stack and my mental model of it to do a depth-first traversal when surfing. That means I go back almost as often as I go forward. But I don't go forward with the "forward" button; I go forward by clicking on a link—a simple mouse operation. And I don't use the back button; use of the "back" button is extremely inefficient, as I have to move the mouse all the way up to the toolbar and click there, and then (most likely) move the mouse back down to the client area for further interaction.
That sort of mouse movement is widely reviled as reasonable UI design for frequent users; so there is a keyboard shortcut, the standard expert user solution. Unfortunately, it's ALT-left-arrow (or, alternately, backspace), which is inconvenient for right-handed users (it's not very convenient for the left hand). Moreover, it would be nice if there was a good mouse interface for it, possibly more discoverable.
And there is: the context menu (brought up by the right mouse button) includes a "back" option. Unfortunately, the utility of this option in Mozilla and Firefox is greatly limited compared to that in NS 3, owing to two design changes which cooperate to make right-mouse-button back nowhere near as efficient as left-mouse-button "forward" (when clicking a link).
In Netscape Navigator 3 (if my memory serves me correctly), when you depress the right mouse button, a context menu appears under the mouse, and the first item is "Back". If you release the button immediately, the menu stays up, and you move the mouse to your choice of options and click again. If you instead drag (without releasing the mouse button) onto an option and release, that option is carried out without a second click being required.
Once you discovered that right mouse clicking brought up this menu, and that "back" was present on it, you might decide to use that as your primary "back" interface. If you did, repeated usage of it would lead to it becoming an extremely efficient operation, because "Back" was always the first option in the menu, so you always had to drag to the same spot in the menu. As Don Hopkins has noted about Pie Menus, this sort of menu selection becomes effectively a gesture: right-down, drag a tiny bit down and right, release—barely any slower than a right-click. But it's not like a "mouse gesture" system: it's easily discoverable, and at any moment you can pause mid-gesture and have be in a sensible, visible GUI state.
Netscape 4 (under Windows) unfortunately ruined the gestural aspect of right-mouse "back" by introducing a UI design rule that required the first context menu item be highly relevant to the clicked-on object. Thus, it is never "back" unless you click on something "uninteresting". This already makes it ineffective; the UI operation isn't "right-minidrag-click on something", but "right-minidrag-click away from anything", which is weird mentally. But even without the mental weirdness, practical implementation issues guarantee that it's error prone. You right-minidrag-click on something you think is uninteresting, away from anything, and suddenly you're viewing an image (because a transparent image covered the region you clicked, putting "View Image" at the top), or you've opened a new window because you were inside an invisible frame. (Nowadays, in Mozilla/Firefox, if you did a search on a page, then some text is selected, and right-clicking away from anything when any text is selected brings up a menu in which not only is "back" not first, but "back" isn't even present at all! So then you get to click away from the menu to close it, then click somewhere to clear the selection—oh wait, clicking away from the menu cleared the selection—that can't be good—and then finally bring the menu up again to get your "back" back.)
Still, I persisted in using this UI in NS 4 because I was used to it and it was convenient; but every so often I would open new windows or view images or various other things.
Then IE, Mozilla, and Firefox took one more step to make this UI inefficient. Windows 95 overloaded the right-click with a drag operation. This causes the right context menu to not appear until the mouse is released; the reason this change was made is detailed by former Mozilla user interface designer Matthew Thomas here. This makes the right-context menu inefficient for users who prefer the click-drag-release style. (Note that other menus in Windows, such as the menu bar menus and the application icon menu and the start menu both support click-drag-release.) Up to and including Netscape 4, the authors of the Windows port approached it the way he suggests:
In short, Windows native shortcut menus are so horrible to use that application developers would be best advised to implement their own shortcut menus which can be used with a single click, and avoid the native shortcut menus completely.
Mozilla and Firefox have chosen to ignore this advice and stick with native platform standards.
If you look in Bugzilla, you will find bugs for every single element that contributes to this problem—"back" being first in context menu; the weirdness of the context menu after a selection; the lack of click-drag-release for the context menu. Most of these bugs have been WONTFIXed or INVALIDed independently, with arguments based on platform standards and UI conventions, or parochial assumptions about the use of the mouse: "It's not hard to avoid images. It's even easier not to use the context menu for non-contextual commands." Even though there are clearly other smart people who recognized the big picture "back" situation and thought it should be a viable UI.
Footnote: Re-reading these comments (I originally looked this up a year or so ago) I am again amazed at the circular reasoning exhibited.
folks, we had to decide which principle was more important for *common use*: 1) prioritize toward convenience, or 2) exposing features within a context (power or mere convenience). We decided that 'usable' power was favored over 'messy' convenience; and, our most common users don't need a replicated main menu buried deep down in an expanse of submenus.At least, it's not how the predominant user would tend to navigate, so we scaled back the presence of page navigation to just within the page context.
This is completely nonsensical; the "common", non-power user is never even going to find the context menu, so what we put in it is irrelevant to them! Also, there's no reason that including "back" in the menu requires including the four item set "back/forward/reload/stop"; the only thing anyone is begging for is "back". Yes, there are plenty of people who don't use this style of "back", or don't need to go back that often; but I'm not sure what else they're going to be doing at anywhere near that rate--certainly not "Open Frame In New Window" (which is certainly useful, but does it need to be that fast that it has to displace "back")?