browserstate / history.js Goto Github PK

Hi,

Thanks a lot for 1.6! It fixed the issue that I reported and more :)

I'm testing 1.6 in FF 3 and Safari 5. I call replaceState when the page loads so that I can save state for back/forward. I pass null for the title and url parameters.

First, I noticed that in Safari, the url gets "?&_suid=493" appended to it. I would expect that in an HTML5 browser, the url shouldn't change since I'm passing null for the url parameter to replaceState.

Second, in both FF and Safari, the statechange event is not called when I refresh the page. The replaceState method is being called in my code, but the statechange event never gets triggered. In Safari, when I look at web inspector, I see:
TypeError: Result of expression 'newState' [undefined] is not an object. history.js:820
In FF, I don't see an error in firebug, but statechange does not get triggered.

Thanks a lot,

Avi

It should only cause one, with the intermediate states being ignored.

If you are to file a bug report, or request a new feature this is the right place.

If you would like help implementing History.js within your application, or general help accomplishing a task please use the GetSatisfaction forum instead:
http://getsatisfaction.com/balupton

Before filing an issue here, be sure to include the following:

• The version of History.js that is affected, if you are using the dev branch then the commit that is affected.
• Which browsers and versions of the browsers are affected and which are not
• Place any sample code on http://gist.github.com (for snippets) or http://jsfiddle.net/ (for reproducible demos) or provide a live direct link to the problem

If you are wanting to contribute code to History.js then be sure to read:
https://github.com/balupton/history.js/wiki/Developers-Guide

Cheers, and thanks for reading!

Hi,

using v1.7.0, problem boiled down to following example:

$("#one").click(function(e){
History.pushState(null,null,'one');
return false;
});

$("#two").click(function(e){
History.pushState(null, null, History.getState().hash+"/two");
return false;
});

Works fine in html5 browsers
In html4 browsers, clicking #one produces http://localhost:9393/#./one where I'd expect http://localhost:9393/#/one (without that dot)
clicking #two produces http://localhost:9393/#one/two instead of http://localhost:9393/#/one/two (missing slash)

tried v1.6 (checked out commit 910f8ff) and that seems to work ok.

Hi!

I am trying to use the master branch in one of our development. I find this library really good looking.

I noticed a few issues during my experiment. I am not sure if these are really bugs though, I am not seeing the code in its total depth yet. So, maybe, I misunderstand things. But, I like to write my observations here.

First of all, I started to write the demo application with the assumption that the statechange event is supposed to trigger on the initial page load as well. (By initial page load I mean what happens when an url representing a given state is force-reloaded in the browser, or such an url is visited as a link from another page, ie, when a page is loaded first, or reloaded completely.)

I think that this is true, the statechange should trigger on the initial page load, and this is a Good Thing. However, during my experimentation I had to realize that this does not happen so in all the browsers which is a pita. I tried to understand things better, and discovered a few issues.

1). On Safari, there is a problem (Safari 5 on MaxOSX). The event is not triggered on the page load. After research, it seems that this is not a problem of History.js, but rather a bug in Safari itself. (Have not tested yet if other WebKit browsers, such as Chrome, are also affected or not.)

I worked this around in our demo by triggering the missing statechange on the domload, on Safari. However, such a problem defies the real beauty of statechange. As an application developer, I would like to use statechange to set a given state in my widget, independently if this happens on the initial page load, or later during popping a given state in the history. I would not need or want to take care of the initial state, I'd rather just implement a single handler. In addition, it is very difficult for an application or widget to find out if the initial event has happened at all or not.

So, for this reason, I believe it would be nice to "fix" this problem of Safari with the initial popstate event from History.js. Then, statechange could work as expected on all HTML5 browsers, in the same way.

2). Without more explanation at this point, I need to mention that I also have problems with the page load on HTML4 browsers, I tested on IE8 only. It seems that in order to make history work correctly on IE, on the initial page load as well, I need to implement both the statechange and the anchorchange handlers. It would be nice not to need this. I still need further experimentation and a deeper understanding on this issue.

3). On HTML4 browsers, it seems that the current code does not create the hash fragments as shown in the documentation. They should be something like this:

www.mysite.com#?state=3/uid=3

• but the hash part gets url encoded (not sure if a problem really, but is this really necessary?) so you end up with this ugliness: ...#/this/path%3Fstate%3D3/uid%3D3
• and, the url path gets repeated after the hashmark. ie: you get
  www.mysite.com/this/path#/this/path%3Fstate%3D3/uid%3D3

... notice how the /this/path is repeated after the #, again, is this really desired, and, needed?

So, I am not saying this is a problem for sure, just pointing out the inconsistency with what you write (imo, correctly) in the documentation page.

4). Finally, a definite bug: line 1121 in History.js is

History.Adapter.trigger('anchorchange');

where, it should be:

History.Adapter.trigger(window, 'anchorchange');

which results in this event not triggered at all.

To close it, thanks a lot in advance if you can take some time in enlightening me about what I think right or what I think wrong in my above observations. I am also willing to contribute to the code and/or tests as needed.

Best wishes,

Balazs Ree

A number of issues have been reported which can either be minor or major depending on your userbase. I'll resolve these sometime this week and get a release out. Will also look into adding data persistance thanks to the work by Scott Gonzalez.

Currently for HTML4 browsers, the entire URL besides the hostname is included in the hash. This could be optimised further to just include the relative path to the mother location.

For instance instead of:
http://localhost/products/history.js/demo/#/products/history.js/demo/?state=2

It can become:
http://localhost/products/history.js/demo/#?state=2
or
http://localhost/products/history.js/demo/#./?state=2

Which is a lot leaner.

@markjaquith found a bug with History.js which prevents the statechange event from being fired if the pushed state contains a anchor in the url. It is known to affect Chrome.

When using history.js in an iframe with IE8-9 ( i didn't test with older browser but the same issue is expected ), If we hit the back button, IE go back one state but the change event is not fired.

History.js v1.7 - Windows Vista - IE8 - IE9

I'm trying to work out how to do AJAX based page redirects (my endpoint tells the page it needs to redirect through a json object). In order to make it so it behaves like a normal redirect, I need to discard the state from the history so that back button doesn't bring you back onto the redirected page, causing another redirect and effectively killing the back button.

It goes something like this:

$.getJSON(url, function(data){
  if(data.redirect){
     History.replaceState({}, "", data.redirect); // redirect is something like /users/1
     // trigger ajaxy redirect
  }
});

This works fine with HTML5 history browsers, but is having trouble with hashchange browsers (IE 9 is the one I've tested with). The back button still triggers the discared state to be hit. I stepped into the code and found that it's because of the way History.js handles the shortened urls to create the state hash. When the state is added to the discarded states, the hash is something like (assuming redirected page was the root url): '/', whereas when the back button is pressed, it compares it to the hash './'... so it doesn't think it's a discarded state.

Any ideas how to fix or work around this?

While using the latest in the dev branch I'm getting an error on HTML4 browsers due to history.html4.js calling History.getShortUrl() at line 560.

I naively tried to comment out the check which then sent the script into a looping frenzy until it locked up (last I saw my hash was like //////////////the-original-address-requested).

Any suggestions for a proper fix? Thanks for all your hard work - this project works great for me on Chrome :)

Hi,

v1.7, I was wondering if you foresee any problems with changing line 1004 from:

tmp = window.unescape(result);
to:
tmp = window.decodeURI(result);

and 1114 from:

result = window.escape(result);
to:
result = window.encodeURI(result);

When using URLs with Unicode in them, I was encountering errors in Chrome and Firefox. In Chrome, if I would encodeURI() the unicode part of the URL that I passed to History.js, it would look corrupt in the location bar. In Firefox, using the straight unicode or encoding it would cause History.js to stop updating the location bar hashtag once it hit a URL with unicode in it. I'm not sure if my fix is correct, but it seems to be working as I desire in both Chrome and Firefox, so I wanted to see if you think this presents any issues?

Thanks,

Matt

You can test ist with the demo files on Internet Explorer, when using prototypeJS and history.adapter.prototype.js.
On line 126 "element.fireEvent" throws an error, when "element" is "window", because window.fireEvent doesn't work in Internet Explorer. Haven't found a solution yet.

In your code, you have some jsdocs with "@ return" and nothing behind (like here https://github.com/balupton/history.js/blob/master/scripts/uncompressed/history.adapter.jquery.js#L27) . When using Google closure compiler, it produce a warning "unexpected end of file". And It's better to put "@ return void".
edit: @return fails

Everything is fine; I have the whole setup working on HTML4/5 platforms but for some reason the address doesn't change nor stops loading when I navigate via the native browser buttons - the page does load but I don't seem to be able to stop the browser continously loading.

I would assume this is iOS only at this point - apologies if this issue has already been raised and covered

The compressed versions are weird. I used this minifier below and now I no longer get javascript errors when combining the various history.js files into a single history-all.js file.

http://refresh-sf.com/yui/

The title says it all. It would be nice to have an adapter for Zepto.js ( https://github.com/madrobby/zepto )

I don't know if this is something that is intended behaviour or not but when I arrive at a url containing a state in IE8 or Firefox it does not trigger a statechange event that I can use to load in the appropriate content.

In IE6/7 it seems to do this automatically but I am having to add following code in on my onload to catch all browsers:

if ('' != History.getHash()) {
    History.Adapter.trigger(window, 'statechange');
}

I am also seeing the issue with a js error being thrown if I paste an html4 url into Safari.

Another quick question was why does the system add a hash state when on the same url as the state? e.g. /foo/bar becomes /foor/bar#/foo/bar just after load. This seems a little ugly and unnecessary when the state is yet to be set.

Sorry if this all sounds negative, other than these tiny niggles this is a great plugin!

If you take a URL that's been produced by History.js using an HTML4 browser and copy/paste to Safari it throws an exception. For example, in the demo:
file:///Users/palexander/Downloads/balupton-History.js-a9ccf1d/demo/index.html#/Users/palexander/Downloads/balupton-History.js-a9ccf1d/demo/index.html%3Fstate%3D2/uid%3D344

This URL is produced using Firefox 3.6, copying and pasting the same URL to Safari 5 results in the following error:
Error: History.js does not support states with fragement-identifiers (hashes/anchors).

The error happens when the initial state change happens after the page load.

Commenting out lines below fixes the issue, but I would imagine it will cause something else to break if I leave it that way.
if ( History.extractHashFromUrl(url) ) {
throw new Error('History.js does not support states with fragement-identifiers (hashes/anchors).');
}

I saw another issue where Safari support had problems, but I believe they were resolved. Please let me know if there's any other information I can provide to assist in troubleshooting.

Scott Gonzalez has recently updated Amplify Store to support multiple frameworks, so will look into adding data persistance.

Hi there,

It seems to me like the data parameter which is provided to the History.pushState method should be able to be any arbitrary Javascript object. However, the only way I was ever able to get it to work was if the data parameter has a state key.

e.g. I tried to do...
History.pushData('some string','My Title','?my+url')

But History.Adapter.bind(window,'statechange', ...) got bugged out state data unless I did...
History.pushData({state:'some string','My Title','?my+url')

If this is intentional then I think it should be documented in the description of History.pushData.

PS: Thanks for this great script, I think it's going to be very useful!

Just curious why the "/" is used instead of the "&"? If someone (like me! :) is trying to get the HTML4-based hash URLs to work across browsers it really breaks things when the translation happens to HTML5 and you get something like this:
?p=notes/uid=977

Rails (and I would assume other back-end systems?) interprets this as:
params[:p] = "notes/uid=977"

Which means I have to do extra processing rather than just ignoring the uid param. I can work around if necessary but it would be really nice to just have the uid as a normal parameter.

Thanks for the great work!

Hi,

Initially I posted my problem first at http://getsatisfaction.com/balupton/topics/history_js_back_button_goes_two_states_steps_back.
After some research I found the the problem is caused by the manually triggered 'onpopstate' event in the end of the body of History.pushState(). Triggering the event consumes the state too early and later when the user clicks browser's back button there is no notification for the last registered event.
I.e. there is a single link clicking on which pushes a new state. Clicking three times on this link and then clicking browser's back button will call twice my 'statechange' handler - once for the second click and once for the first one, but none for the third.

I noticed a possible issue when using pushState with a data object, but no title (set to null) on HTML4 browsers. It works fine on HTML5 browsers.

It seems that the data object does not get saved unless there is also a string given for title. If I give a title, the data object is available and the URLs have the uid present. With no title specified, the URLs do not have the uid value and the data object is empty.

This is on FF 3 Mac and IE 8. No problem with Chrome or Safari.

..jon

Shouldn't this load the correct content, for example if you clicked this link (html4 browsers)
www.example.com/#./page-name
shouldn't it load /page-name not the homepage of example.com?

Or is this not something that is supported?

When you start from any URL in IE7 (or lower) that doesn't include the hash path the state change event can no longer be triggered in any matter.

This is only resolved when you include a hashed file in the path and does not happen in IE8.

It may be caused by the additional functionality of not setting a state change on first page load.

https://gist.github.com/883759

Couple of issues that these address:

1. String.replace() only replaces the first occurrence
2. When comparing hashes, make sure both are escaped

Please take a look at these commits:

https://github.com/robmadole/history.js/commit/d626142e6322504c917118188a87bc46f5b64a5c

https://github.com/robmadole/history.js/commit/a7b3b02e44b24ef2e97db499951a8cc3c566376a

The first commit went down the wrong path. The second I think is correct. I wasn't able to run the tests, I'm just not going to mess with setting up PHP :D

I tried accessing the demo index.php (using php version 5.3.0 on os x) and the page ignores some of the php tags. Not sure if this is my php version to blame or a setting but it was easy to fix by using <?php instead of <? and <?php echo instead of <?=.

permalink

This was removed rather quietly in release 1.4. Some kind of explanation would be nice.

Worked fine in 1.5, broken when upgraded to 1.6, works when reverted to 1.5. Tested on FF4 and Chrome10 on mac

To reproduce:

• Click on stuff to create new states
• Refresh
• Click back (nothing happens except you should get a javascript error)

I narrowed it down to the onPopState function around line 1475:
// Fetch State
if ( event.state ) {
// Vanilla: Back/forward button was used
newState = History.getStateById(event.state);
}

newState ends up being undefined. I borrowed some code from 1.5 to create this:
// Fetch State
if ( event.state ) {
// Vanilla: Back/forward button was used
newState = History.getStateById(event.state);
if (typeof newState === 'undefined') {
stateData = event.state;
stateTitle = stateData.title||'';
stateUrl = stateData.url||document.location.href;
newState = History.createStateObject(stateData,stateTitle,stateUrl);
}
}

which works for me but probably isn't the correct solution..

In a browser that does not support the History API (e.g. Firefox 3.6.x) pushing the same state change twice in a row causes the entire script to stop working. This is repeatable using the demo file.

Are the files in scripts/compressed acceptable for use in a production environment, given that both license.txt and the New BSD License state that the terms of the license must be included in all source distributions?

Thanks,

Matt

Does History work with jQuery 1.3.2? If currently no, is there any workaround worth to try?

First I load this URL in a HTML4 browser
example.com/a/b/c

The hash is automatically added to my URL
example.com/a/b/c#/a/b/c

Can I disable this automatic hash?

I still want to be able to pushState like this
History.pushState(null,null,'/a/b/c?x=1');

Which will change the URL to this
example.com/a/b/c#/a/b/c?x=1

I just don't want the hash added until the first pushState is called. I don't use pushState that often so I would like to keep my URLs short and clean until a pushState is called.

Thanks!

Steps:

1. Change directory to the cloned repo
2. Run python -m SimpleHTTPServer
3. Open Safari 5 and do a reset on the browser
4. Open http://localhost:8000/demo/index.html
5. Click the browser back button

Result:

Nothing appears to happen.

Expected:

Should return to the browser's home screen.

Hi,

It would be helpful to add semicolons to the ends of the minified files. While this makes no difference if the files are including via separate script tags, it causes problems if they are combined into a single file.

Thanks.

Queuing should be used instead of timeouts due to the time it takes for History.go emulation, History.back and History.forward IE6 checks - can cause the current process to be interrupted by a new event. That new event should not interrupt and instead be pushed to a queue of events.

If you pass a Mootools element to be save with the state, the object is gone and all you are left with is an uid.

The change occurs on history.js:310 when it stringifies the obj. Is there a good reason for it?

There needs to be a proper demo to showcase the History.js functionality.

Hey guys, just letting you all know that I'm back from my flight and now ready to tackle the issues and attend to all your feedback. Thanks for everything everyone :)

I just installed History.js on a development site of mine and I am loving what I have seen so far.

One possible issue, or maybe it's just my unfamiliarity with how things should work. I've tested with both the Master and Dev branches.

My anchor href is like: /packaging/timex.php

I'm calling pushState with a data object, a title and the url. On an HTML4 browser (Firefox 3 Mac) The URL ends up looking like:
/#/packaging/timex.php/uid%3D90

I'm seeing similar encoding on the URL for the demo as well, but I'm also seeing other strangeness of the demo URLs. My demo is hosted on a development server and has a path like:
/history/demo/
When I click on the 'Stage 1' button, I get:
/history/demo/#/history/demo/%3Fstate%3D1/uid%3D677
Shouldn't I be getting something like:
/history/demo/#?state=1/uid=1
So not only is the URL being encoded (FF 3 Mac), but it also looks like it is doubling up.

It's a little worse on the dev branch. With dev I actually get:
/history/demo/#/history/demo/%3Fstate%3D1%26_state%3D787

Similiar results on IE 8.

Hi,

Great plugin! I am just starting to test it out in FF 3 and Safari 5.

The issue I am seeing is that pushState does not work in FF when I use a URL like "/some/path". It does work for url "/some/path?", as well as your example "?state=3". When I dont include a query string, nothing happens in FF. It works fine (with or without query string) in the html5 browser (Safari).

I am calling pushState with no state or title params. I am using FF 3.6 on Mac.

Although its not the biggest deal to include a "?" at the end of the url, it looks ugly in both html4 and html5. As you mention in your documentation, html4 browsers url encode it. And in html5 browsers, all my urls end up having this extra "?" even though I have no query string.

Thanks!

Hey mate,

I'm not sure if this is the right place to ask since it is not an issue, but a question. ON my application, I have an onclick event triggering a function which will process the state data and add a new state. I do an AJAX call to get some stuff from the server after the statechange. So far great. But sometimes an user might one to click the same link again, to see if there is new data on the server, but since it is exact the same state data, the 'statechange' is not triggered.

So my question is how can I check if the state I want to push is the same as the current state, so I can sent it to another function?

Thanks for a fantastic plugin

Sol

When we use history.js in an iframe ( like application in facebook iframe for exemple ) it's working fine in all browser except Safari.

In Safari , when we hit the back button, the browser refresh the window and load the iframe content as the main page.

Any known fix about that ?

Safari 5.0.4 on OSX 10.6.6 with history.js v1.7

No 'statechange' events are generated in when the user navigates away from the site using the 'Back' button, then back again using the 'Forward' button. I noticed the issue in the following browsers:

Safari 5.04 (Mac)
Chrome 10.0.648.204 (OS X)
Chromium 10.0.648.133 (77742) (Ubuntu 10.10)

Note that this works correctly in Firefox 5 (tested on OS X and Ubuntu 10.10).

How to reproduce:

1. Open http://www.google.com/.
2. Open the history.js demo in the same tab/window.
3. Click a pushState button.
4. Click 'Back' twice -- now we're on the initial google page again.
5. Click 'Forward' -- we're on the demo start page.
6. Click 'Forward' again -- no 'statechange' events are generated anymore...