[whatwg] Do we really need history.clearState()?

[Brady Eidson]

I think clearState() is a good idea but is just spec'ed poorly.

Imagine the use case of the checkout procedure at an online merchant.

There's normally steps like "enter your address," "choose your shipping method," "enter your CC info," and finally "place your order."  It'd be pretty neat if they used this new API to make it so the user could use the built-in back/forward buttons to switch between the various steps to update the information.

But once the user has finished the "place your order" step and is presented with an order confirmation, all of the previous steps are irrelevant.  The site would be prudent to clear them all out so the user is under the impression they can go back and continue to play with the details of their order.  In this case, clearState() fits the bill greatly!

It is true that what is really being performed is "truncate this part of history."  But we wouldn't to give scripts the ability to control parts of session history they don't own.  And the only way we know which session history entries are owned by a Document is when this new API is used, where the same Document object is shared between history entries.

One might argue that we should give finer grained control - letting a Document remove some of the history entries it owns but not others.  I might be able to think of a use-case for that, but I don't see it being tremendously important.  It could always be added later if there's demand for it.

I think we just need to get the language in shape so the spec is interpreted the same by everyone and is implementable.

~Brady

On Nov 12, 2009, at 12:00 PM, Justin Lebar wrote:

> As I alluded to in the thread "AJAX History Concerns," I'm not
> convinced that we need the history.clearState() function.
> 
> I haven't been able to come up with a compelling case where a page
> would use this.  I guess the idea is that I'm on Google Maps, which is
> using pushState to make a history entry every time I scroll the map.
> If I scroll around a lot, it might clobber my history and make it hard
> to go back to the page I was at before I began looking at the map.
> But it could be nice and at some point (possibly triggered by some
> user action) call clearState.  Then I'd be able to click "back" and
> actually go back to the Document I was previously viewing.
> 
> clearState as it exists doesn't match this use case particularly well.
> If we were concerned about clobbering history, we'd probably want to
> keep the two or three newest history entries and throw out all the
> rest of them.  If you were really clever, you might be able to
> accomplish this by calling clearState and then using pushState to
> reconstruct the part of the history you want to keep.  But getting the
> URLs right would be pretty tricky, especially if clearState took you
> to the last entry for the document, as currently specified.
> 
> clearState is also useless if you don't use this single-document
> pushState model for your site.  If we think clearing the history is
> useful for AJAX pages, I'm not sure why it wouldn't be useful for a
> web application which loads multiple documents.
> 
> I think the use case I proposed is much better served by something
> like history.truncate(numBefore, numAfter), which would remove all but
> the numBefore entries before the current entry and the numAfter
> entries after the current entry.  We'd subject this to the same-origin
> policy, of course, and stop removing entries in a direction as soon as
> we encountered an entry from another origin.
> 
> I'm not sure if history.truncate() is a good idea -- do we really want
> to give pages that kind of control over the history? -- but at least I
> can actually imagine a page using it.
> 
> Perhaps a better idea is leaving this whole issue to the UA, which
> could collapse all the entries from a single origin in the UI.  Then
> we wouldn't need either function.
> 
> -Justin