It would be very convenient if, whenever a link is traversed, the sites above the current site in the go menu do not disappear but are instead put aside in a submenu of the current page title. This would be useful if one needs to go back and forth between two different pages on the same site, or when a link is traversed by accident (which currently removes all later titles from the menu). If a title is selected from a submenu, that submenu becomes the new top of the go menu, and the old top becomes a submenu. For example: The current contents of the go menu (x is the current-site check): x FooBar Soap Foo.com New Products Foo.com Site Index Foo.com Main Page Now, we go back to the site index and follow another link. The go menu, with the submenu expanded, now looks like this: FooBar Soap x Foo.com Contacts Foo.com New Products Foo.com Site Index -> Foo.com Site Index Foo.com Main Page If we select "new products", the go menu changes to this: FooBar Soap x Foo.com New Products Foo.com Contacts Foo.com Site Index -> Foo.com Site Index Foo.com Main Page The title of the root node is duplicated in the submenu so that more than two branches may come from the same root without interfering. Say we go back to the site index once again and traverse another link: x Baz.net FooBar Soap Foo.com Participating Sites Foo.com New Products Foo.com Contacts Foo.com Site Index -> Foo.com Site Index -> Foo.com Site Index Foo.com Main Page There would have to be a limit to the number of branches (a pref?). This feature could affect Bug #10096.

This c'd be better done when the new SH is functional with the new webshell.

Any idea when that'll happen?

Such an implementation would gain one item for every distinct page visited, and one submenu every time a user clicked Back and then followed a new link. This would cause a few problems. * Mozilla for MacOS uses native menus, which have a hard-coded limit of 4 on the level of nesting of submenus. If I follow more than 4 links from the same page, going back to the original page each time, I'm going to lose my ability to get back to the original page again because the menu item for that page has disappeared beyond the 4th nesting level. * In the same browsing situation as above, just going back to the original page becomes harder and harder as the menu item for that page gets pushed out into a more deeply nested submenu. * Assuming Mozilla becomes as stable as we'd all like it to be, this menu would be getting larger and larger as long as we had Mozilla running. The effect of this on system performance would be just as bad as any other memory leak. This is a brave attempt, following on from the Back and Forward button, to invent the Sideways button; but for the reasons given above, I don't think a menu is really the place for it. I would suggest an `Advanced History' sidebar panel instead, which has branches for each link that was followed for a given page in the session history -- and which constantly scrolls/expands to show the user's current node in the tree. To solve the memory leak problem, you'd also want an algorithm to delete the oldest branches of the tree once it grew beyond a certain size.

Concerning the first point: When I wrote "There would have to be a limit to the number of branches", I meant submenus (sorry). A Mac would therefore have an upper limit of 4. I don't see how you could lose the ability to go back to the original page, since to follow several links from the same page you would have to go back to the referring page each time. 2nd point: You got me there (although, ironically, this would not be a problem on the Mac: the parent menu item of a submenu may also have an associated action in that OS). The trick would be finding a max # of branches/submenus that wouldn't be too large. Each user may have a different idea of what this should be, which is why it should probably be a pref. 3rd point: I never said that history truncation shouldn't apply to the hierarchy. I sort of assumed that the oldest branches of the tree would be deleted. I probably shouldn't have. I can see that this could be a problem, especially while browsing a site like Slashdot, where backtracking is the order of the day. However, the upper bound on submenus would kick in here. It would be less of a problem on many other sites, which tend to be browsed in sequence (or at least, backtracking doesn't tend towards link traversal as often). I really think this belongs in the go menu rather than the sidebar. People expect navigation to go in the go menu. Sticking it in the sidebar would only solve point 2, and would make it less convenient for people who prefer to conserve screen space and browse with the sidebar closed. And do we really need four navigation menus: go menu, back button submenu, forward button submenu, and sidebar? That could get confusing fast.

You're right on all of the above. I actually think that this feature, if implemented, should be available from the Back and Forward buttons, as well as from the Go menu (I don't know of anyone who actually uses the Go menu). So the ability for a submenu header to have an action of its own would have to be implemented in XP Menus as well -- with some highlight method to distinguish between those submenu headers which had their own action and those which didn't.

You're right on all of the above. I actually think that this feature, if implemented, should be available from the Back and Forward buttons, as well as from the Go menu (I don't know of anyone who actually uses the Go menu). So the ability for a submenu header to have an action of its own would have to be implemented in XP Menus as well -- with some highlight method to distinguish between those submenu headers which had their own action and those which didn't.

Hey, I use the go menu! When going back or forward by a lot of pages, it's easy to miscalculate and end up on the wrong page. I don't know how this could be accessible from the back and forward values proper, but it would make sense to make it available from their submenus. In fact, if it turned out to be too difficult to implement this in Go due to platform restrictions, I think just having it in those submenus would be a reasonable alternative.

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

I think that what you should see in the Go Menu is the most recent snippet of the history (if the history is a tree, as everyone is hoping it will change to). The three domain in the middle represent the last three domains you visited. Clicking on them would bring you to the last page you visited of that domain. The Go Menu would then change. For your example, at the beginning, you would see: Back Forward Home ____________________ www.excite.com www.mozilla.org bugzilla.mozilla.org ____________________ [UP ARROW] Foo.com Main Page Foo.com Site Index Foo.om New Products [Foobar Soap] In the second part, you would see: Back Forward Home ____________________ www.excite.com www.mozilla.org bugzilla.mozilla.org ____________________ Foo.com Main Page Foo.com Site Index [Foo.com contacts] Foo.om New Products Foobar Soap In the third part, you would see: Back Forward Home ____________________ www.excite.com www.mozilla.org bugzilla.mozilla.org ____________________ Foo.com Main Page Foo.com Site Index Foobar Soap [Foo.om New Products] Foo.com contacts [] means its highlighted. The page you are at is in the middle unless it is near or at the last page you visited and has no siblings. Then it of course is the last entry. If you clicked on one of the domains, it would bring you back to the last site in that domain you visited. The Go menu would change by changing the tree snippet, and foo.com would be added to the recent domains (size of parts of go menu set in prefs). The recent domains is independent of the history meaning if you go back a few domains, it doesn't rewrite those entries. I think this solves the problem.

Ignore the [UP ARROW], that is a mistake.

If you don't do it sooner than M18, it will be too late - time is needed for debugging. I think you should change it to P4 and M16 and get more help. The tree-like history IS DEFINATELY a priority (since everyone wants it) and many people have been putting it off. It is time to start it since Mozilla is about 75% finished. Please update the Summary to read "[RFE] Hierarchical Go Menu And Tree-Like History" since this should go hand in hand with a tree-like history. Please put helpwanted for keywords.

What do you think about the idea I posted yesterday? It would be the best of both worlds - a heirachical go menu without many menus. There have been no responses. Thank you for updating the summary and keywords.

BTW - I still think you should change the priority and Milestone. If you don't think that is a good idea then please say why.

boberb: The Target Milestone and Priority Fields are for organizing workload. A developer, or development manager sets those fields as a means of ranking, in order, tasks to be done. M17 before M18 and P1's before P2's and so forth. By setting this field it means a developer has given the issue at least a cursory evaluation and decided that is when the work will be done. If it's to be done any faster - someone else will have to do it(helpwanted keyword). Moreover, some of the work depends on other tasks being finished first e.g. the landing of the new webshell(noted in the body of this bug). I hope this anwsers some of your concerns.

Bob, I'm not sure about your suggestion. I think it would actually be more confusing than what I layed out. For one thing, it wouldn't be possible to jump to any specific page. You'd have to go to a shared ancestor of that page and the current one, then go to the page you want. This would be a pain, especially if that ancestor page was no longer in cache. For an example of a setup like this in action, go to www.sluggy.com and try to get to a specific comic in a specific chapter of a specific book using the little drop-down menu. You can't go directly, because you can only see a list of the chapters in a book if you are already at that book. With submenus, you can just select the page you want to go to without having to load intermediate pages. And on using indentation instead of submenus: this could also be problematic. The indentation might not be obvious at first glance, unless you used some sort of marking to show the structure (like news threads). It would also get wider the deeper you go. Submenus are more compact, they only appear when you need them. Finally, the separation into domains may or may not be a good idea. But, it certainly runs counter to what people have grown to expect. Also, some sites spread their pages across several subdomains (like www1, www2, etc.), while other domains use subdomains for separate sites (like how simplenet organizes member pages). Listing by subdomains makes sense for the second case, but for the first case only listing by the main domain name makes sense (can you remember whether that page was on the www1 or www2 server?)

see also: "up" navigation, bug 33684

You wouldn't have to go to the parent node of a page first to go to a sibling, all you would have to do was click on that sibling which was organized under its parent's node. If you were at Foo new products, and wanted to go to foo contacts, you would just click on foo contacts. Secondly, depending on the size of the history snippet you set in prefs, you could also go directly to bugzilla or mozilla pages in the same way. If a page wasn't in the history snippet then there are three scenarios: 1) you could click on the first page so that the history moves down. 2) Arrows could be placed on the menu to scroll the history snippet (but that would defeat the whole simplicity). 3) You would use the history since you have gone to many pages since then. The neat thing is, if you went to a site in the middle of the tree, the tree would start growing in the middle as you went to new sites. That stops history bloat (ie many of the same exact pages stored in history).

adding myself AGAIN to cc dunno why removed. HMPH! :)

see extd discussion in bug 15347

erm, that should have been bug 15437.

Garth, I think you misunderstood me about domains. The domains listed would just be so you could jump back to the last domain. The tree would be organized by the order you went to pages. If you went to, in order: www.t.com www1.t.com www2.t.com then back to www.t.com by clicking on a link in www2.t.com, and then to a subpage, you would see - www.t.com www1.t.com www2.t.com www.t.com subpage But then if you clicked on www.t.com on the history and went to a subpage, you would then see www.t.com subpage www1.t.com www2.t.com www.t.com subpage but if you then typed www.t.com into the browser, and took a link to got.com, it would look like this: www.t.com got.com subpage www1.t.com www2.t.com www.t.com subpage so you see - the wouldn't be organized by the domain, but instead by the order you went to the page. If you go back to a page you have already been to even by typing it in the menu bar, then it doesn't add a new part to the tree, but instead starts adding to the old part. Eventually, when a set of branches go to too high a level, it would break it off and place it as a child of the root - maybe when it gets 8 wide or so. ie: 1 2 3 4 5 6 7 When you go to 7 from 8, then 9, it would look like this: 1 2 3 4 5 6 7 8 9 That way, the tree wouldn't become ridiculously wide. If anyone has a better idea, then feel free to tell me. Also, there would need to be two trees - a name tree and a history tree. The name tree would have a root node with a child for every letter and a child off of those for every letter, etc. Nodes would only be added when needed. Then for each node that is the end of a site url, there would be a linked list containing pointers to all the locations in the history tree that have this url. That is an extremely fast way to search, as I used it for a concordance. There are other possibilies for fast search structures that might be better (such as a hash table) but I'm not sure. A linear search through the tree each time a site had to be located would be extremely costly, though. I don't know what would be done about children that are no longer links on the page. But I think it wouldn't hurt to just no worry about them.

IMO wraping ala the 7-9 example is nonintuitive, I propose a better format for the Advanced History sidebar (which i think is a very cool feature). Bear with my crude ASCII art skills here. The word 'host' is used here instead of 'domain', because 'bugzilla.mozilla.org' and 'mozilla.org' would be seperate nodes under this system. Key: + closed expanding tree - open expanding tree - www.mozilla.org / /mozorg.html + freshmeat.net - bugzilla.mozilla.org / /reports.cgi /confirmhelp.html + slashdot.org + www.google.com - opensource.org [/] <-- current page open in this window, bolded + turbogeek.org Explaination of Figure: user opened mozilla, and it went to mozilla.org and snaged file '/' user followed a link, or manually went to /mozorg.html on the same host user followed a link/manually went to an unknown number of pages on freshmeat user viewed 3 pages on the host 'bugzilla.mozilla.org' user viewed an unknown number of pages on slashdot.org At this point, we see a host indented - a 'fork'. There are two ways this could have happened. 1) user went to turbogeek.org (shameless plug for my domain), then did a 'back' (to slashdot.org), then went to the host 'www.google.com'. 2) user opened a new browser window. But see bug 18808, spawned windows need to inherit history.. for this whole fork thing to work, we'd really need to 'borrow' the behavior of IE5 (new windows inherit history and immediatly load the current page from the old window). This is a true fork. IMO, this would greatly enhance the whole history function. Explaination of Bahavior: This systems attempts to conserve vertical space, to fit as much relevant history onto the sidebar without needing to scroll, and to maximize usability. It would be displayed as follows. When connecting to the first host (assuming side bar was open and on History), two lines are added: - <spiffy host icon> <host> <spiffy page icon> <initial page path> Each link/manually entered location on the same host adds another page line. When user moves to another host, the old host is automatically collasped, and we repeat the above steps. Issues: if user goes to foo.org/a.html, then foo.org/b.html, then follows a link back to foo.org/a.html, should we move current marker back up to a.html, and fork if user takes an alternate (not b.html) path. Argument aginst other proposed systems: Garth's proposal to put this all under the Go menu would not allow many entries to be shown, and expanding menus are notoriously bad UI design (*cough*Start Menu*cough*) Brian's proposal for normal flow to be indented, and forks to be at the same indentation level creates SEVERE wraping problems, wasting horizontal space.

I like mozilla@turbogeek's ideas. A lot. If I'm interpreting it right though, wouldn't there be a problem if I kept going back to Slashdot, and following links from there - wouldn't the later links get shifted more and more to the right, eventually disappearing from the sidebar altogether ?

I've created a monster! :) Maybe I'm just stubborn, but I still prefer submenus to indentation, and the "wrap-around" just makes it more confusing. Otherwise, I like Brian's suggestion. Jeremy's suggestion, however, seems a little out of place. I think it's a good idea, but it probably belongs in its own RFE. This bug is turning into a central repository for all ideas for advanced ways of accessing session history, which I think is a little too broad. It was originally just for the Go menu--the "and tree-like history" was added because that would be required for hierarchical access (although in retrospect it probably should have been submitted as its own bug, and a dependency set up).

Move to M21 target milestone.

<CENTER>Here we go... another long entry :)</CENTER> It makes sense that you changed the milestone number for this - at least until we come up with a good solution. :) Don, I like some things about your idea, but dislike others. Let me just clear a few things up - If you go to www.netscape.com/index.html then went to contact.html then to feedback.cgi, it would look like this, right? + www.netscape.com /index.html /contact.html /feedback.cgi then if you went to www.slash-dot.com you would see this: + www.netscape.com - /index.html - /contact.html - /feedback.cgi + slash.dot.com - /whatever page In answer to gabriel's question, there can be a simple thing to stop the same domain appearing over and over. If you call a domain on a higher level in the tree under where it already occured in a tree - ie +www.t.com - [www.r.com] then you called www.t.com/index.html from www.r.com, you would see: +www.t.com + [www.r.com] / index.html but if you called www.p.com from www.r.com and then went to index.html then called www.t.com then www.p.com you would see: +www.t.com + www.r.com - www.p.com / index.html + www.t.com + [www.p.com] so only similiar domains on the same and lower levels of the same branch can be recognized. A problem I see is for sites like geocities. Say you went to geocities/~anders then geocities/~jon etc. they would all appear under the same level of the tree even if they are in different sites an idea is to seperate the pages in a different directory on the server by putting a separator between them, keeping the ones that are closest to similiar together (ie sorting by dir.). Still, that doesn't keep track of navigation order within a domain. It doesn't say what the go menu will look like, and also, it will eventually get bloated too, after people go to a ton of domains. I think one solution to bloating (no matter who's idea we choose) is that whenever a new domain is entered, it should start a new child of the root node(inserted right after the current child). That doesn't say that it is organized by domain, as one domain can appear many times. Also it doesn't show the domain in the history - instead it shows the title of the first page you entered in that domain. A solution to the horizontal bloating on my previous idea (with this new idea incorporated) is that: The history looks like this: +start.html You click the start.html then you see: -start.html +index.html you somehow tell it to open all branches on index.html -start.html -index.html -contact.html -bugs.cgi -feedback.cgi -thankyou.html -etc. -index.html -fun.html -products.html If you wonder why index.html appears after feedback.cgi it is because the person pressed back all the way to contact.html and then clicked on the return to index button. Now you can't even see -etc and -thankyou cause its outta the box (Just pretend). So you can click on index.html and tell it to expand vertically so you can see everything... -start.html -index.html contact.html bugs.cgi ------------- feedback.cgi thankyou.html ------------- etc. ------------- ------------- index.html ------------- ------------- fun.html -products.html Notice that a "-" wasn't placed in front of these that is so people know how it was expanded, it is also separated from the products.html You can click on the root node of the history to have the whole history appear like that. That is how the history snippet would appear in the start menu. Basically, it cycles through the tree by recursively processing one of the child nodes completely and then going through the other child nodes (I forgot what this kinda traversal is called - anyone remember? :). The ---- is a divider and is placed between children nodes of the same level and two are used when going down a level. Actually, the dividers could be left out altogether (which would probably be best for the go menu). After thinking awhile, I think the dividers are not even necessary and would make it look disgusting The algorithm is: node is location in the actual tree treecontrolnode is location in the tree control in the window (I'm using a tree for simplicity) OF COURSE, I didn't debug it so don't yell at me for errors (which I guarantee exist) :) void expand_vertically(node * current, treecontrolnode * controlcurrent) { int i=0; /* First, remove this node and all children from the tree control which removes this part of the tree from the tree control */ controlcurrent->deleteChildren(); if (current->hasChild()) recursiveProcess(current, controlcurrent, 0); /*The checking wasn't really needed, but it doesn't hurt to be careful - it saves crashes */ } level makes sure that the final dividers don't appear (ie after fun.html) so it looks nicer void recursiveProcess(node * current,treecontrolnode * controlcurrent, int level) { level++; for (node * nPtr=current->firstChild; nPtr!=null;nPtr=nPtr->pNext) { treecontrolnode * controlnew = new treecontrolnode; controlnew->setText(nPtr->name()); controlcurrent->addChild(contronew); recursiveProcess(nPtr, controlcurrent, level); if (nPtr->pNext!=null) controlcurrent->addDivider(); } if (level!=0) for (i==0;i<=1;i++) controlcurrent->addDivider(); } I proofread rather quickly, so if you see any significant errors, then feel free to tell me :)

GWallace: In a perfect world yours would be the best solution (The go many implementing the tree as a series of menus). The problem is that menus take up mucho mem, are slow, and don't work on every os. Jeremy: I liked your domain idea and incorporated it into my idea. I want everyone to NOTE that I do not at all mean implementing the history as MSIE did, which was pathetic because it wasn't organized by the way you navigated, but instead by domain. The NS4.x way was good except the history just got too large to handle. I think my idea is the best of both worlds. It is now quite similiar to yours except it is still organized in a tree where going to one page from another makes the former a child of the latter. For everyone for clarification: To sum up the last few entries I had, A tree-like history with the snippet for the go menu as a list would be best. New domains should be sent to the root node, inserted right after the domain you are currently in. Domains can be listed more than once in the tree and (I am adding) should be organized by the time you went to them. That way, as opposed to MSIE's implementation, pages you went to at a particular time are kept together and not all placed in the same place based on domain. Also, doing so keeps the tree from having too large of branches. As going to too many pages within a site can also bloat the tree, there might need to be a limit (8-15) to the number of levels which would cause extra levels to be carried over back to the root node. Finally, if a page title is so long and it is at such a high level it can't be seen, then you can expand vertically as described earlier. The concept used in expanding vertically would also be used to create the go menu, which would have a snippet, and the last three domains that were visited. Basically, the snippet would be created by taking the whole tree, turning it into a list by expanding vertically and grabbing a portion above and below the current history location. ::Brian gasps for air :)

Hi all, I have noticed a lot of activity and discussions on this RFE. Though this bug is assigned to me, I havenot looked in to it, because, I have more higher priority bugs/features assigned to me. It seems the participants in this discussion are way ahead of me w.r.t what should be done and how it s'd be done. If anybody is interested in taking over this bug and implementing this feature, please go ahead. I think the new SH component has the required interfaces to support this feature. If you need more stuff from SH, please let me know. I will schedule it in. Thanks, Radha

I want to take the scope of the discussion back to the Go menu. I agree with Garth (2000-05-24 20:46): An extended hierarchical history in the sidbar is another issue, which should be followed in another RFE. Here is my solution for an enhancement to the Go menu: Make it a tree with submenus, but with the exception of the last history track, which should appear exactly as in Nav 4.x. Somewhat difficult to explain; I use the example of Garth's very first comment (1999-12-11 20:32): The current contents of the go menu (x is the current-site check): x FooBar Soap Foo.com New Products Foo.com Site Index Foo.com Main Page Now, we go back to the site index and follow another link. The go menu, with the submenu expanded, now looks like this (the old history branch, which gets lost in Nav 4.x and Mozilla (by now), becomes an sub-tree): x Foo.com Contacts Foo.com Site Index -> Foo.com New Products -> FooBar Soap Foo.com Main Page If we select "new products", the go menu changes to this (the former history branch is expanded to the main menu again): FooBar Soap x Foo.com New Products Foo.com Site Index -> Foo.com Contacts Foo.com Main Page Say we go back to the site index once again and traverse another link (now we have 2 sub-trees starting at "Site Index"): x Baz.net Foo.com Participating Sites Foo.com Site Index -> Foo.com New Products -> FooBar Soap Foo.com Main Page Foo.com Contacts The main difference to Garth's suggestion: All links previously followed from a page are located in it's primary submenu, not in different submenus. But steps forward in this branch of history are located in additional submenus. This means an interchange of vertical and horizontal arrangement of submenus. Some intelligent algorithm is required to cut the histrory tree at a reasonable point, if it exceeds some limit. I think that I could implement this feature, but not before september or october. This would mean to add it in Mozilla 5.x or Netscape 6.x, x > 0.

Contrary to my words in the last comment I spent some time to write a demo for a hierarchical Go menu. It works the way I suggested, but can't handle frames. I'd like to hear, what you think about it. This demo is based solely on XUL, RDF and JavaScript, so you can install it without compiling any code. If this feature should appear in Mozilla, much work is left to do. It has to be embedded in the current session history. I can't do this work in the near future cause I have not enough time for it and my knowledge is limited, too (currently I haven't even installed a C-compiler on my computer). If somebody else want to do this work sooner, go ahead! Steps to install the experimental hierarchical Go menu (will result in a "XGo" menu right to the "Go" menu; works with M16, should work with newer builds, too): 1. Put previous attachment HierHistory.js, named HierHistory.js, into your chrome/packages/core/navigator/content folder 2. Add the following items in chrome/packages/core/navigator/content/navigator.xul : a) In <window id="main-window" ... > change attribute "onload" from onload="Startup()" to onload="Startup();HH_Startup();" b) Add the following line near the other similar lines --8<----- <script language="javascript" src="chrome://navigator/content/HierHistory.js"></script> --8<----- 3. In chrome/packages/core/navigator/content/navigatorOverlay.xul search for the Go menu ( id="gomenu" ). Insert the following lines after it: --8<----- <menu id="HH_Menu" value="XGo" datasources="rdf:null" oncommand="HH_Goto(event)"> <template> <rule isempty="false"><!-- the other way with isempty="true" does not work properly! --> <menupopup> <menu class="menu-iconic" uri="rdf:*" onclick="HH_MenuClick(event)" value="rdf:http://home.netscape.com/NC-rdf#title" checked="rdf:http://home.netscape.com/NC-rdf#checked" hidden="rdf:http://home.netscape.com/NC-rdf#hidden"> <menupopup/> </menu> </menupopup> </rule> <rule> <menupopup> <menuitem class="menuitem-iconic" uri="rdf:*" value="rdf:http://home.netscape.com/NC-rdf#title" checked="rdf:http://home.netscape.com/NC-rdf#checked" hidden="rdf:http://home.netscape.com/NC-rdf#hidden"> <menupopup/> </menuitem> </menupopup> </rule> </template> </menu> --8<----- 4. If you want checkmarks in <menu> when it represents the actual page, change in /chrome/skins/modern/global/skin/menu.css the lines --8<----- menuitem[checked="true"] { list-style-image : url("chrome://global/skin/menu-check.gif"); } menuitem[checked="true"][disabled="true"] { list-style-image : url("chrome://global/skin/menu-check-disabled.gif"); } menuitem[checked="true"][menuactive="true"] { list-style-image : url("chrome://global/skin/menu-check-hover.gif"); } --8<----- to --8<----- menuitem[checked="true"], menu[checked="true"] { list-style-image : url("chrome://global/skin/menu-check.gif"); } menuitem[checked="true"][disabled="true"], menu[checked="true"][disabled="true"] { list-style-image : url("chrome://global/skin/menu-check-disabled.gif"); } menuitem[checked="true"][menuactive="true"], menu[checked="true"][menuactive="true"] { list-style-image : url("chrome://global/skin/menu-check-hover.gif"); } --8<----- 5. If you want the back/forward buttons to be controlled by the hierarchical Go menu: a) In chrome/packages/core/navigator/content/navigatorOverlay.xul search for the broadcasters id="canGoBack" and id="canGoForward" and change their attributes "buttonaction" from buttonaction="BrowserBack();" to buttonaction="HH_BrowserBack();" respectively from buttonaction="BrowserForward();" to buttonaction="HH_BrowserForward();" b) In chrome/packages/core/navigator/content/navigator.js, nsXULBrowserWindow.prototype, onLocationChange delete the line with content "UpdateBackForwardButtons();"

I am but one person but I believe that a menu will not be good. Not only for the reasons I stated already, but also because menus can be annoying - ie if you want to go back and select another member of a previous menu. Also they can be unwieldy. I also believe the go menu should be totally dependent on the history and that it should contain a list of a small snippet of the current location in history using some sort of traversal. tree snippet: a b c d e f g h go menu: a b c d e f g h It would therefore be (pre order traversal? - I'm a bit rusty and don't want to go look it up). Each node can store its number of children (including direct and indirect) so that it is easy to figure out where to start the traversal. Therefore, I do not believe the go menu should be hiearchical but should contain a list of the contents of the current location in the history (not where the user is on the sidebar but the physical location of the history entry of the current page) - more often than not the snippet would be very close to the end of the history. I will do an example of it some time later.

BTW, NCSA Mosaic 3.0 has a tree-like history in its sidebar. http://www.ncsa.uiuc.edu/SDG/Software/Mosaic/

nav triage team: looked at this bug, it is not a beta stopper. bulk update of several such bugs.

I am changing my mind. I think a hierchical go menu would be a good idea if two things can occur: 1) The go menu needs to be flat - meaning there are not too many sublevels 2) It will work on every OS. I think that menus are implemented seperate from the OS so it would work on every OS. The only problem I see is with performance. Will implementing this slow things down too much on some computers?

BTW: mpt - is the situation with MacOS the same?

Giving it to XPApps team. SH has all the interfaces required to achieve this.

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

There is an additional application for an heirarchical History I didn't see discussed here, and it's one that may be appropriate for the regular History menu. The application is named anchor navigation within a document. That is, <a href="#foo"/> jumps to <a name="foo"/> within the current document, but adds a new History entry even though a new document hasn't been loaded. The anchor names could be used to build an heirarchy off the document TITLE in the History menu. Thus, Document TITLE |_foo |_bar , foo and bar being named anchors accessed by the user. The current behavior results in: Document TITLE Document TITLE Document TITLE Thoughts?

> There is an additional application for an heirarchical History > I didn't see discussed here, and it's one that may be appropriate > for the regular History menu. It isn't discussed here *because* it's an "additional application". One issue per bug please. > Thoughts? Different and (mostly) unrelated feature request. File a separate report for it if you want it; this bug is spammy and offtopic enough already.

This issue is being hashed out in bug 121054 now. *** This bug has been marked as a duplicate of 121054 ***

Neither is this a duplicate (the other bug has no hierarchy, judging from how I understood the spec) nor should such an old bug with so much discussion be closed as dup. REOPENing.

That bug is for implementing as much of the Go menu as is going to be implemented...only the "visited in last x days" and the "site last visited 1-4" stuff will be done, per the spec at http://mozilla.org/projects/ui/communicator/framework/menu_framework/menuproto_screenshots/b/nav/. There's only so much stuff we can put in the Go menu...! *** This bug has been marked as a duplicate of 121054 ***

blake, both bugs are about history, but that's about it as to what they share. The other bugs seems to dublicate the History window/sidebar, which is idea, if you ask me. I find the ideas in this bug much more practical. While browsing to the page I visited 30 seconds ago (but that went away from the history because i happened to open a link after going back) I don't really want to dig though *all* the pages I visited today. > per the spec at It's not a spec, but a "proposal". Just because something lives as HTML file somewhere on www.mozilla.org doesn't make it authorative. Has this part of the proposal been discussed on the newsgroups? The suggestion in this bug has been discussed a lot and is considered a good idea by many people. Anybody who agrees with me feel free to reopen.

I agree with Ben. This bug is *not* a dup. It is a *separate proposal*, and should be considered separately whether it conflicts with the other bug or not (I'm not sure it does). If it is determined that this bug won't get fixed, then fine, resolve it WONTFIX. But resolving it as a duplicate is abuse of the duplicate-resolution feature. This sort of thing is why I proposed bug #98464.

Alright, you have a point. I will need to read through this entire bug, but from what I've read, I think it sounds like a wontfix.

I don't see them talking about a tree like history anywhere in that bug nor does Mozilla have a tree-like history. It just sorts by domain.

Reassigning to a real person.

I can agree with a tree-like history, which stores your browsing pattern. It's normally a line, unless you backed up a few pages, and started a new branch. And every time you select a bookmark or typed in a new url, you'll start a new branch. The result is that you'll have a tree like this : Slashdot +-- Slashdot page 1 +-- Slashdot page 2 +-- url linked from slashdot page | +-- a second url on that same website +-- another url linked from slashdot Google +-- result query 1 page 1 +-- url from page 1 +-- result query 1 page 2 +-- url from page 2 +-- result query 2 page 1 My Daily Newspaper So, my patter was to open slashdot, I looked at 2 pages, and browsed at 2 sites linked from the second slashdot page. Then I opened google (from a bookmark), and started a query related to the 2 urls I found on Slashdot. I found 2 links, each on a different page. Then I went back up to the main Google page, and lanuched a new query, but without results. Then I went to my daily newspaper (from a bookmark or by typing the url) and read the main page, but didn't want to read any further. This tree makes it much easier to navigate in the hisotry, because I can easily differentiate between a url that was found on Slashdot, and one that was found with Google. But I can't agree with the same tree planted in the Go-menu, or on the back/forward buttons. Hierarchical menus can't be that complicated - that's why we have the sidebar in the first place !

This bug has no chance of getting fixed the way it stands. One issue per bug. See bug 187410 that is the new location of tree-like history.

http://Mozwho.mozdev.org has a start at a hierarchical back button. Implementation in chrome .js required creating a entirely additional history datastore due to Bug 128398. Contributors welcome at mozwho.

Reassigning obsolete bugs to their respective Seamonkey owners (i.e. nobody). If you want this fixed for Firefox, change the Product and Component accordingly and reassign back to me.

Filter "spam" on "guifeatures-nobody-20080610".