I am using backbone.js and pushstate. In IE9, it degrades to using the hashtag and AJAX requests work just fine. The issue I have is with refreshing the page. My links are in the following format:
/a_username/a_collection_id
in IE9 if I am on:
/me/collection1
and I click on the AJAX link:
/me/collection2
I get this:
/me/collection1#me/collection2
When I refresh the page however, because the server knows nothing after the hashtag, I am brought back to /me/collection1 instead of the intended /me/collection2.
What is a workaround for this problem in browsers that don't have pushstate?
You could do a check on initial page load and see if there is a hashtag and then do a redirection. Something similar to this:
window.onload = function(){
if (window.location.hash){
window.location.replace("...root url..." + window.location.hash);
}
};
Not the cleanest solution as it will cause a redirect whenever someone lands on a link with a hashtag but it will give you the result you're looking for.
Related
I'm facing a crazy issue with in localhost vs production server.
Basically the issue is: browser back button doesn't have support for traversing in pagination, which works pretty fine in localhost. I am using Ajax update panel for pagination in grid view.
One more interesting stuff is: when I'm clicking on browser back button it appends a 404 URL, whereas I do not even have 404 page on my server.
the URL looks like:
http://www.example.com/404.aspx?404;http://www.example.com:80/domain-abcd/
I could able to travel all the pages in localhost and browser back button is properly responding taking me back to the previous page in gridview.
I am using IIS 6.0 and for rewrite URL Intelligencia UrlRewriter.
For this purpose I use the code below upon page load
form1.Action = Request.RawUrl
Any ideas on how to deal with, and fix these issues?
Please view below links..
http://rchern.wordpress.com/2008/05/11/updatepanel-backforward-browser-navigation/
how can i get the same page with the click of back button of browser
Hope this will help you.
My web app runs under Tomcat, it uses AJAX requests very intensively, and during the development process I have to redeploy the web app intensively too. After the redeployment I usually simply refresh the page knowing that the user session is dropped, but I always get to the scenario described below:
Go to some page, a really big page with many JS-scripts included, that actually makes those intensive AJAX requests.
Stop Tomcat or redeploy the web app.
Refresh the page.
Enter the credentials in the sign-in form to authenticate.
Suddenly get the last AJAX request response in the browser window and the AJAX request URL in the URL bar.
Wow... It looks strange for me that AJAX request URLs appear in the URL bar along with their response in the web page display area. This actually happens to Firefox and Chrome (haven't tested it in other browsers). Unfortunately, I cannot reproduce the same behavior in a simple page written from scratch. Frankly speaking, I don't really understand what happens to such requests and why do browsers "think" if AJAX requests/responses are entered in URL bar by user...
Your possible explanations or hints for such a strange behavior are very and very appreciated. Thanks!
(Perhaps it can help: All AJAX requests are performed with jQuery 1.4.2)
I'm very sorry, as I understood later, the question is not complete, because there was another pitfall I didn't mention, so no one couldn't answer the question in principle. The reason of the bug was hiding in the... <body onunload="..."> tag definition. That was quite unexpected, but that code contained some AJAX request that must be invoked when a user leaves the page. I only realized that the authenicating module (FORM, j_security_check) returned a response (HTTP 302) containing the Location header - so that was the reason why browsers did redirects.
The exact scenario was like that:
Open the page containing <body onunload="some_ajax_here">.
Log out the app using another tab so you could stay at the same page.
Refresh the page so some ajax could be invoked - this AJAX request is not now allowed because it's a secured part of the application (you get the forwarded content of the login page).
Enter the credentials and now oops you get to the result of some ajax directly in the browser window.
As the quick fix, and I hope the final one, I added another request following that AJAX request:
$.ajax({
async: true,
method: "GET",
url: document.location.pathname + document.location.search
});
So the HTML page script simply makes self-page request the last one - j_security_check returns the Location referring the last used HTML page, and the redirect works fine. Perhaps my explanation is not clear and may be not complete or even full of mistakes, but it looks like that in general. I'm very sorry once again, and thank you #ChristopherSchultz!
If using the current Chrome, Firefox, and Safari, when switching between
http://www.facebook.com/my_name
http://www.facebook.com
The side panel for feed and chat, and any chat box actually stays. I thought when the URL changes, the page has to refresh as a whole, but obviously, this is not the case here. How is that done?
On IE 9, the URL actually became http://www.facebook.com/#! and using the "hash" to do ajax without refreshing the page, which is more understandable.
You can change the URL and page history from javascript without actually reloading the page.
See this answer on another question.
Note, that if you type the new URL by yourself and press enter the whole page reloads.
this might be the internal linking in the webpage with hidden DIVs with IDs and onClick those Hidden DIVs get visible with javascript and with AJAX content is loaded it will be a good if you browse the site disabling javascipt
I know there are plenty of plugins can archive this, but I think I want to make a simple one for learning purposes because I have come this far that I can change the url with location.hash when I load an ajax page.
Now I only need to find out - how do I use simply jquery to check there is a fragment on the url when I click back button on the browser?
I came across this simple concept but it works only if I ciick the browser refresh button but not the back button,
$(document).ready(function(){
if(window.location.hash) {
// Fragment exists
var hash = location.hash;
alert(hash);
} else {
// Fragment doesn't exist
}
});
Can you please give me some guide?
Thanks.
You are looking for the hashchange event. But it is not supported the well by older browsers which is why all the plugins exist. Check out the code of Ben Alman's hashchange event plugin to see how it supports all the fun quirks of different browsers:
https://github.com/cowboy/jquery-hashchange/blob/master/jquery.ba-hashchange.js
JQuery has a means of simulating hashchange event for older browsers too - basically it works by polling the URL. You might also want to think about what you want to do with redirects e.g. for authentication) See http://tshrestha.blogspot.com/2013/05/hash-bang-url-fragments-and-http.html
I've search high and low for an answer to this but unfortunately I'm stuck. The problem is only occuring in Firefox (tested IE, Chrome and Safari also - works fine, no errors of any sort). I'll detail the sequence of events to save posting all my code.
ASP.NET MVC 3 application, basic form loads into a jQuery UI dialog
Custom jQuery to hijax the form submit (serialize the form and then $.post to the server - no compiler errors when debugging and post shows up in Firebug without errors)
Http GET (automatically happens) getting the response object from the server (+ success text and XHR), response is plain HTML in this case (again, shows up in Firebug with no errors)
Custom jQuery to change the HTML of the UI dialog from it's current HTML to the response Html - this is where it fails.
I've used javascript alerts to debug the sequence of events and as soon as the post (and get) is complete, everything just... sort of stops.
As I say, only in firefox! Very odd, just wondering if there's any known bugs with ajax and firefox or anybody has heard of a similar situation?
I must also add, that on other parts of my site, this works perfectly in all browsers! The only difference between this form and the other forms that do successfully complete the function is that the response from this form is the same "page" again but updated rather than a new "page". (I use "page" as I got all this working with Javascript turned off first and for graceful degredation)
HELP! Or laugh, either is fine.
UPDATE
I have tried sending a view with a blank model back as the action result - works in every browser except firefox - firefox retains the values from the previous post! And then I got to thinking - that's a trait of firefox isn't it? And maybe that's why the original "re-direct" html response doesn't work?? I think it's time to give up and let people know they can't use Firefox for that particular function!
Ok so I'm answering my own question.
The only way I found to get round it is to use $.ajax instead of $.post and to use the option async : false
Hope this helps somebody.
Rob
Have you tried adding the attribute [OutputCache(Location = System.Web.UI.OutputCacheLocation.None)] to your Action for your GET? It sounds to me like a caching issue.