20659 2013-01-14 05:57:04 +0000 A corresponding "pushstate" event would be very useful in some cases (e.g. read some of https://duckduckgo.com/?q=onpushstate ). My particular usecase is for userscripts for sites that use the HTML5 H [...] 2013-04-12 23:20:51 +0000 1 1 1 Unclassified WHATWG HTML unspecified Other other RESOLVED NEEDSINFO http://www.whatwg.org/specs/web-apps/current-work/#history-traversal P3 enhancement Unsorted 1 contributor ian ian mike w3bugs contributor oldest_to_newest 81318 0 contributor 2013-01-14 05:57:04 +0000 Specification: http://www.whatwg.org/specs/web-apps/current-work/multipage/history.html Multipage: http://www.whatwg.org/C#history-traversal Complete: http://www.whatwg.org/c#history-traversal Comment: A corresponding "pushstate" event would be very useful in some cases (e.g. read some of https://duckduckgo.com/?q=onpushstate ). My particular usecase is for userscripts for sites that use the HTML5 History API, where some non-invasive way of detecting "a new logical page has loaded", so that DOM changes can be applied, is necessary. Posted from: 75.84.96.11 User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_8_2) AppleWebKit/536.26.17 (KHTML, like Gecko) Version/6.0.2 Safari/536.26.17 81319 1 w3bugs 2013-01-14 06:00:37 +0000 Argh. Correction to my comment: s/can be applied/should be reapplied/ 84145 2 ian 2013-03-08 23:41:00 +0000 You know when you've called pushstate, since you just called it... I don't understand the use case here. Can you elaborate? Generally we don't provide events that fire when scripts do something, since it's not needed — if you for some reason don't control all the code that you're running, you can at least just override the things you want to hook and catch them that way (e.g. override pushState with your own method). 86108 3 ian 2013-04-12 23:20:51 +0000 Chris, please reopen this bug if you can provide the clarifications requested in comment 2, thanks.