708179 - Extend History API to access position in window.history

Status: RESOLVED DUPLICATE of bug 741755

(Core :: DOM: Core & HTML, defect)

Description

[Ben Francis [:benfrancis]]

Currently with window.history you can find out the length of the history, go back & forward by arbitrary numbers and programmatically add items to the history but there's no way to find out the current position in the history.

This means that there's no way to know when you're at the end of the history.

I propose an extension to the history API which can tell you your current point along the length of history.

This could either be:
* A historyIndex property which gives you an integer representing your current position
* backLength and forwardLength properties to tell you how many pages you can go back and how many you can go forward (this has the advantage that the values can be relative and allow for trimming of history)

This is needed for the Boot to Gecko browser app.

Comment 1

[Olli Pettay [:smaug][[e-mail]]]

Is there possibly something privacy sensitive in this?

Comment 2

[Ben Francis [:benfrancis]]

If so, then how about canGoBack() and canGoForward() like XUL browser elements have?

Actually, a bigger concern is that the B2G browser may not be able to access the window object of a child iFrame because it may be running in a separate process. In which case, another (asynchronous) mechanism is needed.

Comment 3

[Justin Lebar (not reading bugmail)]

I was thinking it would be

  iframe.getContentProperty("canGoBack", function(arg) { alert(arg); });

Comment 4

[Olli Pettay [:smaug][[e-mail]]]

Have I understood correctly that b2g browser would be a "normal" web page, which would have
iframe(s)? If iframe(s) run in the same process as the main page, there is just
one session history. the browser page itself would be probably the initial page in the
shistory. If there are more than one <iframe>, they would use the same session history, so
the return value of canGoBack might be unexpected.

In XUL there is no session history at all by default. It is separately enabled/created for each
<xul:browser> http://mxr.mozilla.org/mozilla-central/source/toolkit/content/widgets/browser.xml#745

Comment 5

[Justin Lebar (not reading bugmail)]

We're going to have to do something special to sandbox the history objects, since otherwise the inner frame could call history.back() a bunch of times and make the outer window go back!

Comment 6

[Ben Francis [:benfrancis]]

If window.top stops at the iframe would this have the sandboxing effect you describe or is this something else that needs to be done as well?

Note that <iframe sandbox> prevents content in the iframe from "navigating" top (you can then enable it with allow-top-navigation) but I don't know if that includes the history API and I don't think Mozilla implements this yet.

If this needs to be done asynchronously then as discussed before we're also going to need async alternatives for the rest of the history API:
 * back
 * forward
 * go 
 * pushState
 * replaceState

and also the equivalent of other non-standard <browser>-like methods:
 * stop
 * reload

Comment 7

[Justin Lebar (not reading bugmail)]

No, window.top stopping is not (necessarily) the same as history sandboxing.

Why do you need to call pushState() on the <iframe mozbrowser>'s content?

Comment 8

[Ben Francis [:benfrancis]]

Erm, actually yes that is quite unlikely as this is really used from the iframe content itself. I included pushState and replaceState for completeness but now you mention it I can't think of a concrete use case!

Also, history.go() is probably not very useful if you can't access the contents of the session history to see where you're going! In Internet explorer you can pass this a URL (like setting the src attribute of an iframe), but I think the standard is for it to accept an integer as an offset from the current position in session history. If you don't know what's in the session history this isn't particularly useful.

We could probably also do with a method of reading the contents of the history to display to the user in the browser. But I digress, again.