Bug 14080 – Changing the hash doesn't add a history entry

• Status: RESOLVED
• Resolution: FIXED
• Component: History

[Bertrand Le Roy]

In both Firefox and Opera, setting window.location.hash to a new value creates an entry in the browser history, enabling JavaScript applications to meaningfully use the back button.
There were a number of hacks that enabled developers to emulate that behavior on older versions of Safari and Webkit, but those seem to be broken in the latest builds, including Safari 3 beta.
Safari should emulate the Firefox and Opera behavior, which is rational and easy to use.

[Bertrand Le Roy]

This reproes when the page is the first one that's loaded into the browser. It kind of works if another page was loaded first, but then hitting back sometimes doesn't enable the forward button, which makes history only navigatable to the past.

[Maciej Stachowiak]

I can't reproduce this on a current nightly for Mac. I would be highly surprised if this is different on Windows, but it's not impossible.

[Bertrand Le Roy]

I just downloaded the latest Windows nightly and was able to repro. Will try the Mac nightly tomorrow when I get near a Mac.

[Bertrand Le Roy]

Created attachment 16212 [details]
Here's a test page that works in Firefox and Opera

If you browse to the attached page right after opening the browser, click the button a few times, you won't be able to hit back as expected. If you navigate to something else then again to the test page and press the button a few times, you'll be able to hit back and state will be restored correctly, but forward will still be disabled.

[David Kilzer (:ddkilzer)]

(In reply to comment #4)
> Created an attachment (id=16212) [edit]
> Here's a test page that works in Firefox and Opera
> 
> If you browse to the attached page right after opening the browser, click the
> button a few times, you won't be able to hit back as expected. If you navigate
> to something else then again to the test page and press the button a few times,
> you'll be able to hit back and state will be restored correctly, but forward
> will still be disabled.

Using the test page and following the instructions works for me using a local debug build of WebKit r25386 with Safari 3 Public Beta v. 3.0.3 (522.12.1) on Mac OS X 10.4.10 (8R218).

Adding PlatformOnly keyword since this appears only to be a Safari Windows issue.

[David Kilzer (:ddkilzer)]

<rdar://problem/5466939>

[Bertrand Le Roy]

I can confirm that this only affects the Windows build (but that includes the current nightly).
Everything runs smoothly on the Mac version.

[Robert Blaut]

I've checked the test case in the latest Webkit on Windows and it works now as expected. So the bug is FIXED