History.js hash reserves in Internet Explorer and PushState problem

I am implementing a website that dynamically configures its URLs using History.js when new sections are uploaded to the main page via ajax.

This seems to work well, but there is a problem with the hash section in the URL that History.js creates as a backup in Internet Explorer.

Here are examples of page links created using jquery:

function connect_browse_buttons(){ $('.browselink').each(function(){ $(this).click(function(){ var action = $(this).attr('name'); action = action.substring( ('action_browse').length ); browsetype = action; if (isIE){ // remove data object and title to avoid use of SUIDs by History.js in IE History.pushState(null, null, '/public/' + action); } else { History.pushState({oldurl: History.getState()['url']}, "Example " + action, config.wwwroot + "public/" + action); } return false; }); }); } 

The .htaccess file redirects any URLs, such as http://example.com/public/category_a to http://example.com , where javascript parses the URL and loads the corresponding section through ajax requests in the changeState handler.

Javascript validates URLs such as

 http://example.com/public/category_a 

And for equivalent fallback URLs created in Internet Explorer, i.e.

 http://example.com/#public/category_a 

Everything works fine - So:

In Firefox , if I open the site in the root of the site, http://example.com and click on the link above, the content is loaded (in the changeState handler), and the URL is set in History.pushState as:

 http://example.com/public/category_a 

If I then click on another link, the URL is set as, for example:

 http://example.com/public/category_b 

In IE , if I open the site in the root of the site and click the link as indicated above, the content is loaded and the URL is set with a hash like:

 http://example.com/#public/category_a 

If I then click on the following link, the URL is set as:

 http://example.com/#public/category_b 

The problem occurs when I open a page in IE that has been bookmarked in Firefox and does not have a hash in the URL. Take our usual example:

 http://example.com/public/category_a 

If I open this url directly in IE, through a bookmark or by inserting a URL into the address bar of the browser, .htaccess will be redirected successfully, the url will be parsed OK by the js file and the contents will be loaded. However, now if I click on the category_b link, the url is set in History.pushState for:

 http://example.com/public/category_a#./category_b 

I really wanted to set the URL as:

 http://example.com/#public/category_b 

However, History.js seems to take the entire previous url as the base url for subsequent pushStates. I tried setting absolute URLs in History.pushState, but to no avail. As you can see in the above code block, I have an IE specific pushState statement. I tried to configure it differently. How can I find out pushState history to find out:

 http://example.com 

as the base portion of the url to which the hash section should be attached? Or is there a better way to approach this than the one described above?

+8
jquery url internet-explorer pushstate
source share
1 answer

AFAIK, the api history will always use the entire URL (without a hash) that was requested to boot the page. After loading the page, you can use the api history to change what appears after this source URL, or you can use hash changes to change what appears after this initial URL, but there is no way to change it without reloading the entire page.

The only option I know to achieve what you are looking for is to redirect / rewrite your server to your desired base URL, and then pass your path, file name, parameters, hash, etc. to your client a side router / controller. I have to advise against this, because (without unnecessary details) the links from your site hosted on Facebook will always go http://example.com/ or regardless of your base URL.

In my opinion, in my practice, I do not use the api history and instead use hash changes, because it works everywhere. This is not always nice to do, but I think you should strive for the correct web server response for URLs in addition to the hash. This is a particularly ugly URL of my website: http://www.respectfulrevolution.org/road/videos/ian_barlow_finding_our_roots_forest#/road/videos/marcy_westerling_livingly_dying , but when loading in the browser, the server responds with what you see here: http: //www.respectfulrevolution.org/road/videos/ian_barlow_finding_our_roots_forest and then the client controller downloads what you see here: http://www.respectfulrevolution.org/#/road/videos/marcy_westering_livingly_dying which should load the same way : http://www.respectfulrevolution.org/road/videos/marcy_westering_livingly_dying

0
source share

All Articles