If you navigate with pjax to `/foo.html#bar`, the URL bar will change to `/foo.html` while the page is loading, but only add `#bar` when it's finished. There's some debate about whether we should be changing the URL at all while loading, because browsers don't seem to do it until the page starts sending data back. However, while we're still changing the URL, it's worth ensuring that at least that URL is complete.
With a URL like `#%24.ajax`, we need to first decode the value before searching the DOM for the element named `$.ajax`. In Firefox, this is not necessary, as the browser already auto-decodes hash values. Therefore, in Firefox this will perform double-decoding, which could theoretically lead to inability to match anchors that contain a percent-encoded value literally. However, since Firefox also seems to automatically decode values for anchors named via `name="..."` HTML attribute, you're going to have a bad time anyway with named anchors that contain percent-encoded characters literally, with or without pjax.
The test verifies that, in an iframe, we can navigate to another page and then press browser's Back button to restore the previous page. However, on Chrome and Safari in pjax-disabled mode (browser native behavior) doing `frame.history.back()` actually goes back in the top frame, effectively navigating away from the test suite that's running. There doesn't seem a way to carefully sandbox browser history navigation to just inside the iframe. Because this test has the potential to intermittently screw up the whole test suite run, it without mercy as I've already spent countless hours trying to debug this and have better things to do with my life.
After jQuery eval's a SCRIPT tag for the first time, it tags it with an internal flag "globalEval" that is kept even after cloning and prevents the same script from getting executed again. Now reset that property when writing to pjax cache, so that back/forward navigation properly re-executes inline SCRIPT tags.
That's not exactly true, as we require users to specify an explicit `fragment` value if they're dealing with full-HTML responses from the server. This explicit value can be "body" if the user chooses so, but that must be decided on a per-app basis. If no explicit `fragment` value is provided, a full-HTML response will trigger a native reload of the page. Closes #475 [ci skip]