Closed Bug 163274 Opened 22 years ago Closed 20 years ago

Implement pop-up menus on the Back and Forward toolbar buttons

Categories

(Camino Graveyard :: History, enhancement)

Product:
Camino Graveyard
Component:
History
Platform:
PowerPC
macOS
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
Camino0.9

People

(Reporter: shawn, Assigned: mikepinkerton)

References

Details

Sorry if this has already been entered, but I like getting a menu of back and
forward pages when I hold down the toolbar Back and Forward buttons. :)
Shawn, isn't this functionality already provided by the "Go" menu? Chimera's
developers are trying to keep it simple, much simpler than Mozilla.
Summary: Back and forward menus → Implement pop-up menus on the Back and Forward toolbar buttons
I miss this too.
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
So, how do we want to do this? The three current examples are in
OmniWeb/Mozilla[Modern theme], IE, and Mozilla[Classic theme]:

OmniWeb/Mozilla[Modern theme]:
Make a region of the back/forward buttons respond to clicks by showing the popup
menu. For example, click on a small down arrow in the lower corner of the
toolbar item to bring up the popup.

IE:
Click and hold the back/forward button to bring up the menu.

Mozilla[Classic theme]:
Click on a small box to the left of the button that has a down arrow on it.
Clicking this box brings up the popup menu.


I personally prefer the OmniWeb/Mozilla[Modern] way. Any thoughts?

How many history items should be shown? Should we show titles or URLs? I think
10 items with just the title would be good. Maybe fewer titles, depending on the
size of the popup. 
*** Bug 153413 has been marked as a duplicate of this bug. ***
QA Contact: winnie → sairuh
I miss this feature alot, I find using the Go menu clunky and unintuitive. We've
been pulling history menus off the back button since Mosaic.

I'd vote for the Mozilla style, a small arrow/region of the icon representing a
place to click to get the menu
I don't like the idea of making a normal button act like a pop-up button.
Pop-ups have a very consistent look and feel across the OS X HI. That gives the
user instant recognizability for the control. Also note that the finder has an
extra toolbar button to do this same thing.

As an alternative, consider Bug 181810.
For some other options, yada yada yada, 
Bug 182395: Path toolbar item
Bug 182144: Combo box for tab-local history

Re comment #3, the Finder is also another "current example" if you consider the
path toolbar item.

I realize that every other browser does it this way, but to me it seems broken.
I don't really get how the back and forward buttons should be encapsulating
history. They are verb widgets not noun widgets, and it's always seemed a bit
discordant to me to have the history connected to them. More specifically,
there's the problem of having a button that doesn't look like a pop-up button
acting like one.
> I don't really get how the back and forward buttons should be encapsulating
> history

I think this is faily clear, even to beginner users. Click once to go back one
site. Click the popup to go back 2 or more sites.

Going forward isn't quite so simple (see bug 177959 for a discussion), but works
by similarity with Back.
> I think this is faily clear, even to beginner users. Click once to go 
> back one site. Click the popup to go back 2 or more sites.

I agree that it's clear, but not that it encapsulates the concept of history.
Thus at least for me there's always cognitive dissonance in using the controls
in IE that do that.

Also it bothers me to have a two-button button. (it requires much more mousing
accuracy to hit it). To require Click-hold or Ctrl-Click to get the popup
resolves that, but makes it less clear.

I still like my idea of having a combo-box location bar (bug 182144) that pops
up the history. I think it has an equal obviousness factor for newbies and avoid
overloading the back/forward buttons. The mockup I made is lousy though.

I like the idea of a tree-based history too (bug 177959). It's going to be
tricky to think of a way to display it IMHO. THe only tree view UI I like is the
columns view in nextstep and now finder.
Bevel buttons in OS X (and previous Mac OS's) have a pop-up menu option by
adding a downward pointing arrow. Check out the AppearanceSample app distributed
with the Developer Tools and go to the 'Grab Bag' tab, and look at the
'Downward' bevel button. I don't see this as that much different and it should
probably adopt that behavior. One thing I do like about the Mozilla behavior is
a right-click opens up the history without click-hold, but that might not be
possible with the standard Cocoa toolbar (it normally displays a context menu
with options for the toolbar). 

One other point is that deviating from standard behavior in other browsers
(especially the browser that unfortunately has a large majority of the
marketplace) is a mistake unless it presents clear benefits to users (e.g.
tabbed browsing). If you want to get people to switch to Chimera don't make
things needlessly different.

I think this should happen as a control-click (right-click) on the back and
forward buttons. That seems the logical place for additional "Back" and
"Forward" related commands, which is what we are talking about. I think the
tiny, tiny triangles in some browser implementations are horrid. They are way to
small as targets, and don't fit with the OS standards.

If we do have a menu here then it should operate like the "Go" menu does now,
context sensitive to the current window/tab. On the other hand, that would let
the actual go menu do more, such as display more complete history.
Re: Brad's comment in 12

The downward arrow should be just to show that there is a menu available, not as
a hit target. A right-click (or control click for the mouse impaired) to bring
it up immediately would be my preferance as well, but the default behavior of
the Cocoa toolbar is to change toolbar settings if you context-click in a
toolbar. I'm all for changing it if possible to make things more convenient for
users, but then I don't see the issue over using real tabs either.

Using click-hold in addition to right-click would follow the typical context
menu behavior Mac users get from other browsers and some system behavior (like
items in the dock).
Comment 10 is not true, 2 buttons are faster to access than 1 drop-down menu
with everything inside.
Comment 12 is incorret, Ctrl is reserved for the Customize menu
(icon/text/small...).
The click and hold on Back/Forward is the only possibility if we want a
consitant way to navigate, see Bug 185306.
The small arrow on B/F is not a click target, just an indication of a bevel.
Don't reinvent the wheel. Comment 11 is right.
I was only suggesting that a control click in the toolbar could stand to be a
bit more context-sensitive (different if you control-click on the actual back
and forward buttons than if you clicked in a blank area of the toolbar).
Brad, that's not possible the standard Ctrl-menu already change if you click on
an item (Remove item) or just in the toolbar but not on an item (Remove item has
disappeared).
What can be done is to only show the two small down-arrows only when the mouse
is over, like in IE. Apple use that concept also, see iChat Buddy list
'Available' area, very neat.
Stephane,

> Brad, that's not possible the standard Ctrl-menu already change if you click on
> an item (Remove item) or just in the toolbar but not on an item (Remove item has
> disappeared).

you can overcome that limitation by subclassing the Cocoa toolbar class and
changing the behaviour, and possibly other ways as well. Generally the behaviour
of cocoa widgets can be changed in almost any way, if there's a strong enough
desire to do it (since it requires work as it 's not the default behaviour)
Simon, you are right. I was trying to say that it would not be a standard
behavior. I think it would be bad as they try to adopt known way of working, see
Bookmarks toolbar trying to mimic the Toolbar, eg: reorder item if Cmd is
pressed only.
Yes, the I.E. back button is a good example. You still have to either control-click or hold 
down and click to get the context-sensitive menu. I like that idea; is that what you are 
suggesting? The menu in iChat does the same thing no matter what modifiers or length 
of time you hold it down, so it is less relevent except for the cool mouseover cosmetic 
effect.

I prefer not having to hold down and wait, if a standard behavior like control-click can be 
made to work. O.K., I will shut up now.
No I don't think so.
The only solution is the hold and drag to get access to the menu.
Ctrl-click should work in the standard way, to edit the toolbar.
That the arrows appear only when mouse is over or not is not important, nicer 
that's all.
*** Bug 188192 has been marked as a duplicate of this bug. ***
So concluding:

1) I think we should use the IE/Mozilla method, putting a small vertical arrow
on the arrow end which opens an X number of steps back or forward in history
depending on the button. But in our case we should use click and hold. (Bug
159224 would probably help?)

2) The big problem with the Finbder like combo box is that it would literally
duplicated the Go menu. The beauty of putting menu's under the back and forward
menu's is that those histories would only be linked to teir specific directions.
The Go menu lists all (10 steps?) of the windows history while the back menu
would only list sites you visited previous to the current page, and the forward
menu would only list pages you visited after the current page. 
So in reply of Comment #7, there is a very obvious reason why the history menu's
should be there. It's the only logic place where people will look and expect
this feature to be. And I can't think of any other way we could do the same trick.

Well Simon what are you gone do :)
Mike what are we going to do? v1.0? or not at all?
i think we should look into this, given that safari does it.
Assignee: sfraser → pinkerton
Status: ASSIGNED → NEW
Target Milestone: --- → Camino0.9
I haven't used Chimera/Camino in some time -- been busy with video projects. 
The 20040208 nightly build is the first one I've tried for some time.

This 'enhancement' is something that I thought had been fixed some time ago.

Mike, gotta give you credit for Camino.  By and large, I like it better than
Netscape 7.1 or Safari 1.2.  It's tightened up vastly since the last time I
tested a nightly build.  But it's still a work in progress.  This is one of the
things I miss greatly, coming off of Safari and Netscape.

Personally, I don't care if you, or some other code jockey take Safari's
approach, or the Netscape 7.1 approach.  Just put it in somehow.

If you press me for an opinion, as a longtime Mac user I find "click and hold on
the back [forward] button" the more Mac-like approach, but folks on other
platforms might find the Netscape 7.1 approach easier to grasp.

Have a lovely day.
So Mike what's holding you from making a nice patch for this ;) Oh that's right
Simon siad he would do so. Come on guys this is one of our most requested for bugs.
yes, this is our most frequent request for sure. i just don't have time to work
on it now. anyone else?
I had some code to add dropdown menus to the buttons at some point. I'll see if
I can find it.
landed on trunk and branch
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.