15437 - nsISessionHistory needs to be scriptable

Status: VERIFIED FIXED

(Core :: DOM: Navigation, defect, P3)

Description

[Ben Goodger (use ben at mozilla dot org for email)]

...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.*

Comment 1

[Radha on family leave (not reading bugmail)]

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.

Comment 2

[Ben Goodger (use ben at mozilla dot org for email)]

[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.

Comment 3

[Brendan Eich [:brendan]]

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

Comment 4

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 5

[Ben Goodger (use ben at mozilla dot org for email)]

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)

Comment 6

[Ben Goodger (use ben at mozilla dot org for email)]

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.

Comment 7

[Radha on family leave (not reading bugmail)]

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.

Comment 8

[John Morrison]

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

verified.