If using
window.location.href = window.location.href;
to reload a page (without re-POSTing) is not bad practice, what should we make of JSLint's "Weird assignment" complaint?
EDIT window.location.reload() is not suitable when you don't want to POST the form data again. In some browsers it provokes the "Resend form data?" which is best avoided when not needed.
UPDATE I did some very brief testing and found:
Chrome 12 and Safari 5.0.5 on Mac do not re-POST with .reload()
FF 2.0, 3.6, 4.0, 5.0 on Mac present the user with the "resend form dialog" with .reload(), .reload(true), and .reload(false)
IE6, IE8(standards), IE8(IE7 mode,standards) in XP; and IE9 and IE10-tech-preview in Win7 behave the same as FF on Mac
window.location = window.location.href works the same as window.location.href = window.location.href in all these browsers.
Here's the test script.
Try this
window.location = window.location.href;
It is indeed a weird assignment to assign something to itself. Sounds like more of a warning than a complaint.
I myself would prefer to use:
window.location.reload()
Edit: but that would repost the form now wouldn't it. Here's a post on SO about the same thing: php reload page without posting data
It is a weird assignment, JSLint is right. The issue is that setting the variable has the side effect of reloading the page. I would code this as window.location.href = window.location.href + ''; to avoid JSLint errors and put a comment explaining what it does.
Related
I'm having issue redirecting a webpage on all browsers. I created a custom page for a client about a year back on SHOPIFY and now the redirect function no longer works.
I was originally using document.location.href = "/cart" and all worked well. But I recieved a call from him today saying the page wont redirect anymore on his IPhone.
I changed it to window.top.location.href, this fixed it for most browsers except safari. I understand that the best way for this to work on all browsers is the document version. But that seems to have been out dated this year.
setTimeout(function(){ document.location.href = '/cart';},1000);
Checking the user agent of the browser and if it's safari we can do a different tailored version of a redirect, just haven't found out how to do this on the new safari yet.
#stanislav seems to have the same issue from this link, I suspect we will start to see the number of people with this issue growing.
Why isnt window.location.href= not forwarding to page using Safari?
Thanks to all for the input and suggestions, hoping to get the resolved soon.
try upgrade , Safari version 14 fixed this bug.
I am developing javascript code with visual studio. Everything is working wWhen I run the application first, then I changing some value of javascript variable but browser not showing right result. The old result is appearing.
var validationResult =validate("username");
var message = "Welcome, ";
if (validationResult) {
message += username;
$("#status").css("color", "green");
} else {
message += "Guest";
$("#status").css("color", "red");
}
In this example, first run on browser shows right result, but I changed the parameter of validate method as "invalidUser" but result did not changed. I thing browser is caching values. Should I clean browser history every run? Is there any clean solution for Internet Explorer or Firefox?
I think your browser is caching resources, not values. It could also be your server who is caching.
If you have the firebug plugin/extension in firefox you can disable page caching while developing on a per site basis.
Just install firebug, open it, go to the net tab, click options (little arrow on the tab itself), select disable caches.
http://getfirebug.com/
You can force to clean the cache with this javascript
window.location.reload(true);
with a falase argument will do the opposite
I am updating the url with something like this:
window.history.pushState(null, "Page title", "/?param=" + myParamValue);
This works fine, but when the user hits the back button, the url gets updated but the page does not reload.
I have an ajax routine that updates the content but if possible I don't want to mess with re-implementing back/forward navigation, and I just want the page to reload in case of the user hitting back/forward browser buttons.
Q: Is there a way to force the page to reload the given url on browser back/forward actions from the user?
Bonus Q: also, what if the browser doesn't support window.history.pushState on older browsers? Shall I surround that code in a try/catch block?
if(typeof window.history.pushState === 'function')
//handle your url rewriting
else
//support for older browsers
As for your question about back-button support, the link provided in the comment provides very nice implementations for the feature
You should take a look at this jQuery plugin, it might be useful for you:
http://www.asual.com/jquery/address/
I found it reading this thread:
https://stackoverflow.com/questions/116446/what-is-the-best-back-button-jquery-plugin
I hope it helps.
About the old browser question, I don't think you have to bother with that because you are using ajax, which requires a modern browser too. The main question is: who will visit your web site? If it's mainly people over 40yo, maybe you should bother...
Just my opinion ;)
Edit: Be careful with IE9, it's not handled in it. thx to nbrooks for the info
I have a script in my JavaScript file where I need to open a new file with a hash already set, something like:
function search(queryString){
window.location.href = "dosome.php#" + queryString
}
because dosome.php is the page where I have all the scripts for the search...
I know it sounds like a hack, but I cant spend more time rebuilding everything. I'm just trying to fix it temporarily.
It works in Firefox and Chrome, but for some reason, it doesn't work in Safari-- it doesn't send the URL with the hash. Safari sends:
domain.com/dosome.php
instead of
domain.com/dosome.php#queryvalues
What could be the problem?
If your server on dosome.php does some redirects, the hash is NOT retained, at least on Safari 4 and IE8. Chrome and Firefox work well.
In order to test this, try entering the URL http://yourdomain.com/...dosome.php#... in Safari's address bar and see if Safari keeps losing the #. (Test both with w/o www, even a simple www redirection loses the #.)
If this is the case, there is nothing you can do server-side because the #... is not sent to server; it's the client who is supposed to not lose it during navigation.
IS this done from the same page? Meaning, dosome.php?
Then try using location.hash,
location.hash = "#somestring";
I had a similar problem.
The following code was failing on an iPhone 5 in Safari:
window.location.href = 'http://example.com/result#somehash'
Safari was redirecting to just http://example.com/result/
It was working correctly in Chrome on the same phone as well as on the desktop.
I noticed it was adding the forward slash to the end and wondered if just adding a forward slash between the hash would work.
It did!
I changed my code to this and it worked:
window.location.href = 'http://example.com/result/#somehash'
Notice the / before the hash.
I'm working on some old AJAX code, written in the dark dark days before jQuery. Strangely, it has been working fine for years, until today when it suddenly stopped firing its callback. Here's the basic code:
var xml = new XMLHttpRequest(); // only needs to support Firefox
xml.open("GET", myRequestURL, true);
xml.onreadystatechange = function() { alert ('test'); };
xml.send(null);
Checking the Firebug console, the request is being sent with no worries, and it is receiving the correct XML from the request URL, but the onreadystatechange function is not working at all. There's no javascript errors or anything else strange happening in the system.
I wish I could just rewrite everything using jQuery, but I don't have the time right now. What could possibly be causing this problem??
A further update - I've been able to test my code in a different browser (FFx 3.0) and it was working there, so it must be a problem with my browser. I'm running Firefox 3.5b4 on Vista, and I've tried it now with all my addons disabled with no luck. It's still really bugging me because I was working on this site yesterday (with the same browser setup) and there were no problems at all...
Actually I just took a look back in my Addons window and saw that Firebug was still enabled. If I disable Firebug, it works perfectly. If I enable it, it's broken. Firebug version 1.40.a31
is the url malformed?
have you tried putting the whole thing in a try-catch and alerting the errors (if any)
is it failing on an authorization check?
does the url in question require http-auth? (though there should be state changes in this case, I'll admit)
edit:
I have a really funny thought here. Are you using firefox 3.5 beta4? I develop a firefox extension for a browser-based game and recently discovered some odd behvaviour. With my extension or firebug observing the ajax requests made from the page, the script ccreating them would never get calledback. The request would be correctly observed and processed by both firebug and my extension (I could observe what was sent and received)... but the page itself would never hear from the request again -- like it had disappeared into a black hole.
Try turning off firebug (or at least turn off listening to 'Net' for that domain) and test it again
Known Firefox bug affecting Firebug; see http://code.google.com/p/fbug/issues/detail?id=1569&q=xhr&colspec=ID%20Type%20Status%20Owner%20Test%20Summary for details :-)
It seems unlikely that onreadystatechange would stop working. Is it possible that the 'alert' function has somehow been disabled or overridden? Can you replace the alert with some code to make a visible change in the page, and check its functionality that way? (I know, its a stretch, but it just seems so strange that onreadystatechange wouldn't work!)