id	summary	reporter	owner	description	type	status	priority	milestone	component	version	severity	resolution	keywords	cc
16339	pushState Test Case	mdawaffe		"This isn't a useful bit of code, just a test case to ground future pushState work for 3.2.  Or be ignored by future pushState work for 3.2 :)

Attached is a test case for determining browser behavior when using pushState.

The numbered links use AJAX and pushState.  The ""Other"" link is a real (non-AJAX) link to an external site.

If the state of the page is refreshed via AJAX, you'll see a var_dump( $_POST ).  If the state of the page is refreshed by a page refresh, you won't.

An example of something this test says is broken in Safari 5.0.3 (6533.19.4):

 1. Load the page (state = 0: pageload)
 2. click ""One"" (state = 1: ajax)
 3. click ""Two"" (state = 2: ajax)
 4. click ""Three"" (state = 3: ajax)
 5. click ""Other"" (state = external site: pageload)
 6. go Back in browser history (state = 3: ajax or just history?)
 7. go Back (state = 2: ajax or just history?)
 8. go Back (state = 1: ajax or just history?)
 9. go Back (state = 0: ajax). Everything is fine up to this point, though it's odd we do an AJAX request to get here.
 10. refresh the page once, either by CTRL-R or by hitting enter in the URL bar (state = 3: ajax). That's wrong.  What happened? Why are we here?
 11. refresh the page a second time (state = 0: pageload). As expected.

An example of something the test says is broken in Chrome10.0.642.2 dev:
 1. Do pretty much anything.  Chrome Dev fires a popState event on the first page load.

It could be a badly written test, or a badly written implementation of push/popState handling, or both.  These are the kinds of scenarios we'll need to test, though."	task (blessed)	new	normal	Future Release	Administration		normal