[whatwg] AJAX History Concerns

[Justin Lebar]

> "The title [argument to pushState] is purely advisory. User agents might use the title in the user interface."
>
> But unlike the URL which actually changes in the Document object and is therefore exposed to the DOM, this "purely advisory" title change is hidden from the DOM.  I'm questioning the reasoning behind this distinction and am curious if it was intentional or not.

What I did in my Firefox patch (which should be checked into trunk
within a few weeks, I hope) is use that title only to identify the
history entry in the pull-down back-forward menu (what's shown when
you click the down arrow next to the forward button in Firefox).

If you want the rest of the UI (e.g. browser title bar) to match up
with this title, you have to set document.title.  In fact, if you
pushState with title 'Foo', then navigate back and then forward, the
history entry's title will be reset to the document's title.  (I
intend to write something detailing tricks like these once we land the
pushState patch.)

On the one hand, the implementation as it is allows developers some
control over the history entry title independent of the document
title, and perhaps that's useful.  On the other hand, most use cases I
can imagine for setting the history entry title are only useful if it
persists between back/forwards.

It appears in my testing that if you do pushState("title1");
document.title="title2" Firefox shows "title2" in both the local and
global history, so setting document.title appears to subsume most of
the functionality of pushState's title argument.

We could make the API change document.title and remember that change
between back/forwards, but I think that would be unnecessarily
complicated.  After a pushState, you'd get a new document which shares
all mutable state *except* its title with its sibling.

Unless there's a compelling use for it, perhaps we should simplify the
API by getting rid of the title parameter altogether.  One can pretty
easily update document.title on popStates manually.  But perhaps I'm
missing something; I recall at one time being convinced that the title
parameter was important.  :)

> [Given] A1 - A2 - B1 - *B2* - B3 - C1 - C2
>
>> "When this method is invoked, the user agent must remove from the session history all the entries from the first state object entry for that Document object up to the last entry that references that same Document object, if any."
>
> In my original message I liberally interpreted this to mean the new current entry should be a copy of "B3" but without the state object because, clearly, we just "removeState()"ed.

I don't think removing the entry from the history implies that we
clear its state object.

Certainly the spec could be clarified, however.  I don't think that
Marius's reading, here that B1, B2, and B3 would all be removed, is
completely unsupported by the text.  But I also don't think that's
what we want.

If I understand things correctly, we always remove the current entry
after a clearState.  So perhaps the language could be

"When this method is invoked, the user agent must remove from the
session history all the entries from the first state object entry for
that Document up to the second-to-last entry that references the same
Document.  The current entry is then set to the one remaining entry
for the Document."

That said, we didn't implement clearState when we did
push/replaceState because it's hard to get right and we don't
currently have a compelling use case.  There are probably lots of
things we'd change if we were going to implement it -- for instance,
why go back to the last entry instead of staying at the current one?
But that's probably a conversation for another thread.

-Justin