- From: <bugzilla@wiggum.w3.org>
- Date: Mon, 04 Jan 2010 18:48:14 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=8629 Summary: history.pushState should clear forward history Product: HTML WG Version: unspecified Platform: PC URL: http://dev.w3.org/html5/spec/Overview.html#dom-history- pushstate OS/Version: Windows NT Status: NEW Severity: normal Priority: P2 Component: HTML5 spec bugs AssignedTo: dave.null@w3.org ReportedBy: fishd@chromium.org QAContact: public-html-bugzilla@w3.org CC: ian@hixie.ch, mike@w3.org, public-html@w3.org history.pushState should clear forward history The spec currently says: "If the method invoked was the pushState() method: Remove from the session history any entries for the Document from the entry after the current entry up to the last entry in the session history that references the same Document object, if any. If the current entry is the last entry in the session history, or if there are no entries after the current entry that reference the same Document object, then no entries are removed." I believe this behavior is undesirable. Instead, pushState should clear the entire forward history regardless of which documents are involved. A major use case for history.pushState is to eliminate the dummy reference fragment navigations used by many apps to add entries to session history without causing a "real" page load. In that case, the app author wants to simulate a real page load, and an important UI component of a real page load is that the forward navigation button becomes disabled. It seems strange when a "navigation" doesn't result in a disabled forward button in the browser UI, so an app developer may be unsatisfied using pushState in place of reference fragment navigations. Moreover, Firefox has implemented pushState in a manner that clears the forward history. The Mozilla folks seem to favor their implementation. There is also support in the WebKit community for changing WebKit to match Firefox instead of what is currently spec'd. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Monday, 4 January 2010 18:48:16 UTC