[whatwg] AJAX History Concerns

[Ian Hickson]

On Wed, 11 Nov 2009, Brady Eidson wrote:
>
> When pushState() or replaceState() are called with a URL argument, the 
> document's current address is changed.  This has a lot of side effects 
> in that it is exposed to scripts and the DOM and most modern user agents 
> would update their UI to show this.
> 
> However, this same section takes care to point out "The title is purely 
> advisory. User agents might use the title in the user interface."  
> Indeed, many user agents would show the title of the current page at the 
> top of the browser window or tab, in their back/forward list, and 
> possibly in their global persistent history.
> 
> 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.

The idea is that the string you would put into the back button or history 
menu is not the same as the string you would put into the title bar or 
bookmarks (i.e. not the same as <title>).


> The following text describes clearState():
> 
> "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.
> 
> Then, if the current entry was removed in the previous step, the current 
> entry must be set to the last entry for that Document object in the 
> session history."
> 
> Imagine the following scenario:
> 
> A document has 5 state entries.  
>
> They each have a different URL as follows:  
> http://www.example.com/page.html?1, http://www.example.com/page.html?2, 
> http://www.example.com/page.html?3, http://www.example.com/page.html?4, 
> and http://www.example.com/page.html?5
>
> The current entry is the 3rd entry.
>
> A script calls "clearState()" so these entries are all cleared out, 
> including the current entry.
>
> Since the current entry was removed, the current entry after the 
> clearState() call is changed to be the last entry for the Document.
> 
> My reading of the spec is that after clearState() returns, the entries 
> 1-4 will be gone completely, the state object for entry 5 will have been 
> cleared, and entry 5 will now be the current entry.
> 
> This has the side effect of the URL for the current entry - 
> http://www.example.com/page.html?5 - not matching the current URL of the 
> document - http://www.example.com/page.html?3
> 
> Is my understanding of what the current entry should be correct?
> If not, what am I missing?
> And is the disjoint between the Document's URL and the current entries URL correct?
> If not, what am I missing?

clearState() was not properly fixed when we changed pushState() and 
replaceState(). I've removed it altogether for now.


On Thu, 12 Nov 2009, Brady Eidson wrote:
> 
> document.title = "Old title";
> replaceState("state object", "New title", "http://example.com/index.html?2");
> alert(document.title);
> 
> What does the alert show?

"Old title".

document.title is often used to include things like unread count in a mail 
client or RSS reader. That's orthogonal from the state you would want to 
show in the back button ("Inbox", "Spam folder", "Settings", or whatever).


On Thu, 12 Nov 2009, Justin Lebar wrote:
> 
> 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.)

That seems like a bug.


On Thu, 12 Nov 2009, Brady Eidson wrote:
> 
> After more thought and more input from others, this is what my current 
> thoughts have boiled down to - Is there a compelling reason why the 
> title parameter is here and that we can't just rely on the document's 
> title as it existed at the time that pushState() or replaceState() was 
> called?  A use case someone can think of that isn't possible otherwise?

Is the use case above -- where the current title and the title you'd want 
in the history don't match -- provide an adequate use case?

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'