...for use in creating smarter session history UI. is there any reason it is not? (see email from brendan) http://lxr.mozilla.org/seamonkey/source/xpfe/appshell/src/nsSessionHistory.*

This is in my laundry list. shall look in to it this week. Brendan's email says something like, Ben needs scriptable session history, in the form of a tree navigable by JavaScript. can you explain what the plan is for the smarter Session History UI.

[suggestion by sfraser] if you are at page A, and you surf to B you go back to A, then surf to C. then go back to A, and want to go forward to B. But the forward button will take you to C, not B, B is gone. Trying to think of a way to maintain *all* pages visited recently in the popup menus associated with back and forward.

How about two dimensions, or "railroad normal form": write each history list from left to right ("Back" to "Forward"), then look at the vertical dimension. A A -> B A A -> C Squish out the subsumed lines (all the "A" lines): A -> B A -> C B is "Up" from C, C is "Down" from B. A can be related to itself the same way; don't stress that this is really a tree (grandma doesn't grok computer science). Unfortunately, the Go menu uses "Up/Down" for "Forward/Back" -- no matter, there would not be "Up" and "Down" buttons on the toolbar in any case, so let's use the other dimension: imagine each XPMenu item in the Go menu having an optional pull-left widget and pull-right widget, so you could see alternatives (such as B when you're at C). Hmm, maybe just pull-right -- who cares what was older in time order of navigation, we merely want to get to alternatives. Thoughts? How hard would this kind of menu be, given XPMenus? /be

you don't even need xpmenus, methinks stuff like this would work on the old native ones too :) There may be a way of doing this that doesn't involve session history, but what I do need is some way of navigating the history graph via JavaScript for this to work (so that i can explore all the branches downstream from a particular page.) e.g. at page A, having returned from performing several navigations to sub-pages and their sub-pages. The actual format and display of the associated forward button popup is what is now troubling me. I can think of three possible layouts - Horizontal, Vertical and Flat. Horizontal works like this: If you've visited pages C D and E from A, and visited sub-pages for each of those, you'll have a popup that works like this: [ FORWARD v ] (submenu for page C) | Page C > | | Subpage 1 | | Page D > | | Subpage 2 | | Page E > | | Subpage 3 | each page travelled to from the current page has an associated popup. This popup is filled with a linear list of sub-sites as with the current 4.x popup. (See question [1] below) Benefits of this approach: Clearly Hierachical, sorts data neatly and easily. Cons: Perhaps not as convenient given that grandma now has to move her mouse into the submenus to activate "forward" sites Vertical works like this: A series of popup menus, each for each different subpage, with the default one (as in 4.x) populating items in the standard menu: [ FORWARD v ] | E Subpage 1 | | E Subpage 2 | | E Subpage 3 | | -------------- | | Page D > |_________________ | Page C > | C Subpage 1 | -----------------| C Subpage 2 | | C Subpage 3 | | C Subpage 4 | ------------------- Pros: Nicely hierachical, neatly arranged Cons: None that I can think of, other than longer menus. This is an easier system for grandma to use as the default sub pages are shown in the actual popup, so she can access them quickly, or if she wants to go forward to a previous page, they're available from popups further down. The Flat Approach simply throws everything into one menu. I'm not fond of this, as it confuses the linear navigation path that the session history buttons have typically shown. Question [1]: The examples of Flat and Vertical I have given have used popup menus to contain sub-pages, as the 4.x session history buttons show a linear progression of sites, and I sought to maintain that. One could argue that it's not really necessary in the Vertical layout, with a subpages list loading for the default site, and just items for the other sites. When you click on an item for one of the other sites, you go there, and the default list updates to include the downstream path for that site. (as opposed to the popup menu listing these sites in the example above). The benefit of this is that it gives one-click-access to these alternative paths, whereas with popups, you have to bury the link to the alternative path in the popup (unless I can associate an oncommand handler to the popup menu invoker, which doesn't sound right). The second question is how complicated should we get with this? With popup menus we could nest things infinitely deep and allow navigation of the history with the session history button ;) I think this is to be avoided in favour of a simpler approach. Below is a modified form of my Vertical proposal above, which I think is the ideal system: On Page A Chose "Page C", on Page C: [ FORWARD v ] [ FORWARD v ] | E Subpage 1 | | C Subpage 1 | | E Subpage 2 | | C Subpage 2 | | E Subpage 3 | | C Subpage 3 | | -------------- | | -------------- | | Page D | | Page F | | Page C | ------------------ ------------------ No popups for D, C or F, going to that page switches the default path (the subpages listed above the separator) over to the path for that particular channel. I have an idea what I said might be hard to understand. I'll draw up a diagram later today that explains this.

some adjustments to my last diagram to make it easier to understand: It is a combination of "vertical" and "flat" ideas: On Page A Chose "Page C", on Page C: [ FORWARD v ] [ FORWARD v ] | Def A Subpage 1 | | Def C Subpage 1 | | Def A Subpage 2 | | Def C Subpage 2 | | Def A Subpage 3 | | Def C Subpage 3 | | ------------------ | | ------------------ | | Page D | | Page F | | Page C | ---------------------- ---------------------- (where Def = default, as in 4.x)

Just to clarify a bit further: All branches are managed by the menu described above. This is the forward button menu. The back button menu is simply a linear history of pages previously visited. This is because you never invalidate pages in your back menu by going to new sites (these only invalidate new pages). One invalidates pages in forward session history more often. The placement shown here is inconspicuous and unlikely to encroach in a negative capacity on the default behaviour.

Session History has been XPIDLised. The basic implementation is in. I will be looking in to removing webshell dependencies later this week. Handle to session history can be obtained in JS thro' browserInstance. nsIBrowserInstance.idl has an attribute "SessionHistory" which can be used to access methods that don't use a webshell as an argument.

Much thrashing for something that was done 14 months ago: http://lxr.mozilla.org/seamonkey/source/xpfe/components/shistory/public/ verified.