We need to identify if the user will be going back a page or forward a page in new unified drop-down history. It would get very confusing not having some sort of indication which way the user would be navigating. IE7 does this by put an arrow to the left of the page title to tell you if you'd be going back or forward. Also puts a check next to current page to also help let you know where you'd be going. See screenshot.

(Mike Beltzner wrote in bug 386228 comment #20) >>> - it might be nice to see if we can emulate the IE7 style use of -> and <- >>> arrows when hovering over the other menuItems >> >> IE7 uses glyphs similar to check-mark and radio-dot which would require two new >> native appearances in order to get color and size of these arrow right. I'd >> prefer not having to do that and just use the tooltips instead. I've however >> added classnames to make it easy for themers to achieve this if they so wish. > > wfm

Ahh so it does, I still think some sort of visual indication would be nice...as how IE does this with the back/forward arrows.

Looks good to me Dão :)

Just noticed (or remembered) the tab overflow arrows, couldn't we just use those to save on not adding two more images?

Note that this may conflict slightly with bug 389478

Actually, instead of doing this would a cleaner solution be to just use the status bar? That would eliminate the need for not only this but also the tooltips (since the status text is instant but the tooltips require a small idle wait). e.g. if I hover over a menu item that will take me back the status bar will say: Go back to http://www.google.com or for forward Go forward to http://www.apage.com We can use URLs since we already get the title from the dropdown. Maybe we should put quotation marks around the URL?

(In reply to comment #10) > Actually, instead of doing this would a cleaner solution be to just use the > status bar? No, that would be very, very annoying to have to look up and down the screen to read the text while scrolling down the list.

>Note that this may conflict slightly with bug 389478 As I commented over there, replacing the selected item's favicon with an arrow should work great. >No, that would be very, very annoying to have to look up and down the screen to >read the text while scrolling down the list. I'm not in favor of this as well, but then again I'm also on a mission to turn the status bar off by default. Note that I just filed bug 415018 to add a history item on the bottom of this menu.

intentionally not touching pinstripe

(In reply to comment #12) > but then again I'm also on a mission to turn > the status bar off by default. Why would you do this? Current downloads and the root name of the website when visiting a secure site are displayed there, for instance. + all other add-ons which adds icons there. I sometimes explain to users to look at the URL displayed in the status bar before clicking a link, to make sure it really goes to the website the link pretend to go. I would hate to tell them to enable the status bar first. But that's unrelated to this bug.

(In reply to comment #14) Opera has the statusbar off by default and I used it a lot and I never missed it. The idle wait for a tooltip while hovering a link is there but people don't look at the link often it tells nothing anyway. If people end up on a page they didn't want to go to they can click back. And the domain is already displayed in the locationbar.

The solution for this simple function of showing if it's back/forwards, that should exist, does not lay on another toolbar. Not only is this confusing, cluttered and in-consistent to people who do have the status bar on, it won't be seen by those whom don't show it. People should not be forced to show the bookmarks toolbar to see smart bookmarks or bookmarks toolbar items. They should also not be forced to keep the status bar shown for things like download info or whether there going back/forwards. It's to be a real mish mash of things thrown on other toolbars creating problems. A back/forwards arrow in the drop-down list should be apparent per IE7, and in the main history drop down too for the same reasons, plus consistency.

Checking in browser/base/content/browser.js; /cvsroot/mozilla/browser/base/content/browser.js,v <-- browser.js new revision: 1.974; previous revision: 1.973 done Checking in browser/base/content/browser.xul; /cvsroot/mozilla/browser/base/content/browser.xul,v <-- browser.xul new revision: 1.435; previous revision: 1.434 done Checking in browser/themes/gnomestripe/browser/browser.css; /cvsroot/mozilla/browser/themes/gnomestripe/browser/browser.css,v <-- browser.css new revision: 1.185; previous revision: 1.184 done Checking in browser/themes/winstripe/browser/browser.css; /cvsroot/mozilla/browser/themes/winstripe/browser/browser.css,v <-- browser.css new revision: 1.176; previous revision: 1.175 done

Dao, as I see this wasn't done for Proto. Should I file it as a new bug or are there special reasons not to integrate it for OS X?

(In reply to comment #18) > Dao, as I see this wasn't done for Proto. Should I file it as a new bug or are > there special reasons not to integrate it for OS X? see bug 416728

Verified with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9b4pre) Gecko/2008022504 Minefield/3.0b4pre and under Linux.

I think this needs to be applied in the same way, to the History drop down for consistency. Seems little good reason to apply this in one history drop down but not in another.

Are you talking about the History menu on the menu toolbar? If so or even not, you should open a new bug.

20080229_2116_firefox-3.0b4pre.en-US.win32.zip after bug 414389 checkin, favicon stay there, no replacement. https://bugzilla.mozilla.org/show_bug.cgi?id=414389#c41