Bug 33160 – history.pushState should clear the entire forward history

• Status: RESOLVED
• Resolution: FIXED
• Component: Page Loading

[Darin Fisher (:fishd, Google)]

history.pushState should clear the entire forward history

see http://www.w3.org/Bugs/Public/show_bug.cgi?id=8629

i believe it would be better if history.pushState cleared
the entire forward history regardless of which documents
are involved.  this way the forward browser button will
become disabled in response to pushState, which seems
desirable to allow pushState to be used to simulate a
page load.  (reference fragment navigations clear the
entire forward session history.)

also, firefox has implemented pushState by clearing the
entire forward history.  when i mentioned this on the whatwg
mailing list, they were surprised to find that the feature
was spec'd differently, and Jonas said that he preferred how
they had implemented pushState.

i think webkit should change to match firefox.

[Brady Eidson]

With no one having shipped an implementation and therefore compatibility not yet being an issue, I would personally r- any patch that changes our behavior without the spec being changed.

Why did mozilla disregard the spec for their implementation (or did their implementation predate the spec)?

In your w3.org bug, you state "There is also support in the WebKit
community for changing WebKit to match Firefox instead of what
is currently spec'd."

I'm curious - I don't feel strongly about this one way or the other - but what support in the WebKit community are you referencing?  Besides this bugzilla, I haven't heard about this yet.

[Darin Fisher (:fishd, Google)]

> I'm curious - I don't feel strongly about this one way or the other - but what
> support in the WebKit community are you referencing?  Besides this bugzilla, I
> haven't heard about this yet.

Maciej gave his support for this change.  (Sorry that doesn't necessarily equate to WebKit community support.)  I think that might have been private email :(

[Darin Fisher (:fishd, Google)]

Also, I should have included this link to the whatwg discussion on this topic:
http://www.mail-archive.com/[e-mail]/msg19615.html

[Brady Eidson]

This is an easy change and it makes sense to align with "the other implementor" on this.

That said, we really need to keep lobbying on the spec...

[Darin Fisher (:fishd, Google)]

> That said, we really need to keep lobbying on the spec...

I've already spoken with Ian Hickson, and he is also supportive of changing the spec.  I believe that changing our implementation to match Firefox will help support the case of having the spec corrected.

[Darin Fisher (:fishd, Google)]

Created attachment 46608 [details]
v1 patch

[Ian 'Hixie' Hickson]

Spec is updated.

[Brady Eidson]

Comment on attachment 46608 [details]
v1 patch

The indirection of insertItemAfterCurrent() is no longer necessary.

The only reason the private insertItemAfterCurrent() was added in the first place was to differentiate between a pushState() and an addItem().  Now that the distinction is removed, I'd rather see the body of insertItemAfterCurrent() moved back into addItem(), and have pushState() call addItem().

(Otherwise, looks good)

[Darin Fisher (:fishd, Google)]

> The indirection of insertItemAfterCurrent() is no longer necessary.

Yeah, sounds good.

[Darin Fisher (:fishd, Google)]

Created attachment 46646 [details]
v2 patch: insertItemAfterCurrent removed

[Darin Fisher (:fishd, Google)]

Landed as http://trac.webkit.org/changeset/53324