Little fix

[hyperkun]

Hello, I've noticed that, due to workaround made for compatibility with Webkit browsers, in Firefox your library ignores first "onpopstate" event, so user is not able to go to the first history state. Here's my suggested fix - use that workaround only when user agent is a Webkit browser.

[jzaefferer]

There's an issue in Firefox, I can agree with that. Though the suggested fix is not good enough. We need a feature test of some kind, instead of just sniffing the useragent.

[hyperkun]

Well, I can't imagine how this feature detection may work. But I'm sure that if this test ever be implemented, it will overcomplicate things, and "Simple History" will stop being simple :)

[jzaefferer]

You're probably right about that.

I need to do some research on the current state of things. Its silly that one browser would trigger the event on page load, the others don't, and then they just stick with that.

[jzaefferer]

My attempt at getting this fixed on the spec level: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18405

Could take several months though until it gets the editor's (hixie) attention.

[hyperkun]

That's great! But still, it means that your library will be unusable for that months (or even for years, until browser developers adopt this spec).

[jzaefferer]

Yeah, I need to check out your patch again, I don't really want to wait. A solution without UA-sniffing would be so much nicer...

[balupton]

Here is the complete listing of issues I've found between browsers while developing History.js: https://github.com/balupton/history.js/wiki/The-State-of-the-HTML5-History-API

Getting this stuff fixed browser side is ideal, so I commend that effort and would happily take part in it if you'd like. Until then, the only way I know of that brings complete compatibility between all browsers is History.js because every browser does behave differently (at one point or the other).

[jzaefferer]

So according to your chart, its just Chrome that fires the initial popstate event, but no other browser does it. I wonder what MS does in IE10 though.

[jzaefferer]

Btw. my bug report got closed as a duplicate, but the "original" got "RESOLVED FIXED". I don't understand how that addresses my issue, but I hope UA developers do: https://www.w3.org/Bugs/Public/show_bug.cgi?id=18605

I need to find or create a WebKit/Chromium issue to the buggy Chrome behaviour, since that spec fix should clarify the issue.