229957 - Add a Toolbar button to activate the History Manager (if not already open)

Status: RESOLVED FIXED

(Camino Graveyard :: Toolbars & Menus, enhancement)

Description

[Jasper]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040101 Camino/0.7+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7a) Gecko/20040101 Camino/0.7+

Add a Toolbar button to activate the History Manager (if not already open) and
bring it to the front with focus.  The button can be off by default and
available through toolbar customization.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Josh Aas]

Do we really want this? Opinions?

Comment 2

[Jasper]

Attachment: History toolbar icon

I'm sure this wouldn' be to hard to implement and it could provide a our users
an easy way to acces history without having to remember a shortcut.

Comment 3

[Josh Aas]

This comment from BrowserWindowController.mm is what makes this bug so difficult:

// History is a slightly different beast from bookmarks. Unlike 
// bookmarks, which acts as a toggle, history ensures the manager
// is visible and selects the history collection. If the manager
// is already visible, selects the history collection.
//
// An alternate solution would be to have it select history when
// it wasn't the selected container, and hide when history was
// the selected collection (toggling in that one case). This makes
// me feel dirty as the command does two different things depending
// on the (possibly undiscoverable to the user) context in which it is
// invoked. For that reason, I've chosen to not have history be a 
// toggle and see the fallout.

The problem is, what happens to the history toolbar item when history is
selected? You can't hit it again and return to what you were doing, but it is
really confusing to not have that option (i.e. disable the history toolbar item).

This bug should not block 0.9. Changing to 1.0.

Comment 4

[Smokey Ardisson (offline for a while; not following bugs - do not email)]

Will the problem in comment 3 be ameliorated once the bookmark manager opens its
own tab or window (bug 215235), or does that exacerbate the situation?

Comment 5

[wrc_fan]

(In reply to comment #3)
> This comment from BrowserWindowController.mm is what makes this bug so difficult:
> 
> // History is a slightly different beast from bookmarks. Unlike 
> // bookmarks, which acts as a toggle, history ensures the manager
> // is visible and selects the history collection. If the manager
> // is already visible, selects the history collection.
> //
> // An alternate solution would be to have it select history when
> // it wasn't the selected container, and hide when history was
> // the selected collection (toggling in that one case). This makes
> // me feel dirty as the command does two different things depending
> // on the (possibly undiscoverable to the user) context in which it is
> // invoked. For that reason, I've chosen to not have history be a 
> // toggle and see the fallout.
> 
> The problem is, what happens to the history toolbar item when history is
> selected? You can't hit it again and return to what you were doing, but it is
> really confusing to not have that option (i.e. disable the history toolbar item).
> 
> This bug should not block 0.9. Changing to 1.0.

Not sure if it's a solution or not, but if you choose show history, and then
click the bookmarks icon, the history disapears leaving you back where you were
before

Comment 6

[Samuel Sidler (old account; do not CC)]

Maybe we should make an exception and allow the history icon to also hide the
history and take you back to where you were in browsing. No?

Whatever the case, I can't believe we don't have a history item (I didn't
realize it before). This should definitely be added for 1.0.

Comment 7

[Mike Pinkerton (not reading bugmail)]

done. does exactly what the menu item does, shows history and that's it.