Today, I noticed this issue in IE11.
A simple JavaScript redirect (made via location.href = 'newhost...';) causes the browser to crash.
Does anyone have any idea how can this be fixed?
If it helps this happened using ContactForm7 on wordpress using this method: http://contactform7.com/redirecting-to-another-url-after-submissions/
Internet Explorer doesn't always play nice with location.href or window.location.href in javascript. i.e. more so the href function...
Try using:
window.location.assign("newhost.."); // or
window.location = "newhost..";
window.location:As described in more detail here.The Window.location read-only property returns a
Location object with information about the current location of the
document.
Though Window.location is a read-only Location object, you can also
assign a DOMString to it. This means that you can work with
document.location as if it were a string in most cases:
window.location = 'http://www.example.com' is a synonym of
window.location.href = 'http://www.example.com'.
There is a solution to this problem in a WordPress forums post here: https://wordpress.org/support/topic/redirection-crashes-ie-11-perfect-for-all-others
KookRoss says:
I found a solution to this, its an ugly one but it does get around the
issue for me.
on_sent_ok:
"$("#post-440").empty();window.location.replace('https://www.url.com.au/thank-you/');"
Where post-440 is the ID of the div which surrounds the form. Put
simply your post led me to the belief that IE is somehow passing that
form again before doing the redirection, this uses jQuery to clear
that entire page of content (including the form) before doing the
redirection.
Its a hack way to get around the IE issue but so far its working in
all browsers for me including IE11.
If you still get this error even using Assign in IE 11 when redirect from an event, you can use:
setTimeout(function ()
{
window.location.assign("newhost...");
}, 100);
To get around the problem
Related
I am using this type of line in an JS response
if (history && history.pushState){
history.pushState(null, null, '<%=j home_path %>');
}
but when I click back in the browser, I see the JS code of the response instead of the previous page.
Is there a way to make the back button work so it would re-request the page of the last url (before home_path as pushStated in?
Update:
I've found this.. it seems other have the same issue with.. History.js doesn't fix it either
So to confirm some of the comments there.. This happens only in chrome
What I think
I think the root of all this is that the popstate requests the same type of the pushstate document (js response). What needs to be done is on popstate request the html response.. I just don't know how
More updates:
seeing http://railscasts.com/episodes/246-ajax-history-state it mentions to use
$(window).bind("popstate", function() {
$.getScript(location.href);
});
this solves the issue but according to understanding jQuery $.getScript() withtout ajax caching it will add timestamps.. which pollutes the url.. turning it off makes it not work again with the same effect..
Anyone knows how to solves this?
Even more Updates
I tracked the trails of the issue all over the interweb and ended with an issue in chrome which points to a rails issue (firefox works fine however) and an issue in rails-ujs concerning not including Vary Header in the responses
Example can be found here
I am currently playing around with doing
response.headers['Vary'] = 'Accept'
which seems to solve the problem, at first look.
If anyone has the same issue, please check it and let me know
You need to add a listener to the popstate event
window.onpopstate = function(event) {
//load the page
};
When the back button is pressed the url is changed and then the popstate event is fired. It's your responsibility to load the details in your popstate listener that match the changed url.
A nice popstate example
Some browsers fire a popstate event when the page first loads, causing an infinite page loading loop. This can be avoided by adding the following check
var loadPage = window.history.state;
window.onpopstate = function(event) {
if (loadPage)
//load the page
};
Then set the loadPage to true when pushState is called
history.pushState(null, null, '<%=j home_path %>');
loadPage = true;
This technique works in all browsers that support html5 history api.
It happened my with sinatra & chrome.
Solved it with:
$.ajaxSetup({ cache: false });
I've tested this code on my browser using a local HTML file and I've gotten a console security error:
SecurityError: The operation is insecure.
history.pushState(null, null, '<%=j home_path %>');
I can see how manipulating browser history may be considered a potentially dangerous behaviour, so I guess you should check that this is not happening for you as well. Try using the Firebug Javascript console. It is also possible that there might be differences in behaviour between local and http:// HTML files.
Said this, for what I've seen the last element of the history array is basically the current page, so if you want to change the previous one, you might do it by using two pushState() commands - first you push the previous element that you desire, then you push the current path again. If I understood your problem correctly.
I'm trying to do a redirect using the below code:
<script type="text/javascript">
window.location.href = "http://google.com"
</script>
FF and IE work as they should. Chrome doesn't.
The request above to http://google.com, gets a 'canceled' status in Chrome browser > Development tools > "Network".
I've tried several other functions:
location.href = url
location.replace(url)
document.location = url
location.assign(url)
window.open(url, '_self')
Same code pasted within a local html file works fine.
Below is the redirect request that it's canceled by chrome: http://pastebin.com/hD36M1RG
Any clues?
Thanks
I was getting a similar problem, the issue was a button submitting a form while executing the window.location.href = ... code.
I had to put type="button" in the button attributes to prevent it from submitting.
Try without window., it helped in my case. I had used location.assign() instead of window.location.assign() and worked.
I was doing the same thing. A quick patch was to add a little delay before the redirect using setTimeout.
I had a somewhat similar issue, (but it did not work on Firefox either). The problem was just that i forgot to add http:// in :
window.location.href = `http://${ window.location.host }/pages/${ name }/`
using setTimeout worked for me, and i'm facing this problem with vue-router, tring to redirect to an auth page in 'beforeEach' hook.
I ran into a problem about vue here . Use vue.nextTick (function () ()) solved it.
Vue.nextTick(function () {
window.location.href="/***/****_view.action
})
It appears that Chrome wants to first complete some (or all) of the outstanding AJAX calls before redirecting or reloading the page, so it is worthwhile examining your traffic.
For me, it happened because multiple AJAX requests were being sent at the same time from within a setInterval function executing at a high rate.
I had to clearInterval in order to get the window.location.href request to not get cancelled.
That would explain why setTimeout worked for some people above.
I have a situation where a PC user's browser (I don't know which browser is it) doesn't have support for location.href, http://www.w3schools.com/jsref/prop_loc_href.asp.
JavaScript is on. Cause fancyBox shows up login popup, which result is - location.href change to ./admin.php?act=loggedok (as example)
Can anybody tell me how to detect this and how to process this issue?
Is this possible to lock out this JS code?
location.href = "http://google.com/";
the location object of the navigator is supported everywhere.. what you can do is to make a simple check if location is arround and then react to it as you need..
if ( window.location){ //or if (location in window) for modern browsers..
window.location.href="www.google.com";
}
else{
alert("please enter www.google.com into your address bar"); // :P
}
Btw; in a noscript tag, you cant do any javascript, so you cant "react to the user having javascript off". But you can display additional html in such a way, that shows the user he still lives in the 90's and should update his IE3 and enable javascript ;)
You need to be sure that Javascript support in user's browser is turned on.
As you can see on w3schools web site it is supported by all main browsers.
This link can help: Mozilla: location
why don't you use
document.location.href = 'http://google.com/';
instead?
It works on all browsers unless they have javascript disabled
The problem is either that javascript is not supported, turned off, or the browser does not support the location object which is basically shorthand for window.location. thus use:
window.location.href="http://www.google.com";
As Andron said all major browsers should support it unless they specifically have javascript disabled. You can tell the user about this using the <noscript> tag.
What is the difference between JavaScript's
window.location.href = window.location.href
and
window.location.reload()
functions?
If I remember correctly, window.location.reload() reloads the current page with POST data, while window.location.href=window.location.href does not include the POST data.
As noted by #W3Max in the comments below, window.location.href=window.location.href will not reload the page if there's an anchor (#) in the URL - You must use window.location.reload() in this case.
Also, as noted by #Mic below, window.location.reload() takes an additional argument skipCache so that with using window.location.reload(true) the browser will skip the cache and reload the page from the server. window.location.reload(false) will do the opposite, and load the page from cache if possible.
If you say window.location.reload(true) the browser will skip the cache and reload the page from the server. window.location.reload(false) will do the opposite.
Note: default value for window.location.reload() is false
The difference is that
window.location = document.URL;
will not reload the page if there is a hash (#) in the URL (with or without something after it), whereas
window.location.reload();
will reload the page.
If you add the boolean true to the reload
window.location.reload(true) it will load from server.
It is not clear how supported this boolean is, W3Org mentions that NS used to support it
There MIGHT be a difference between the content of window.location.href and document.URL - there at least used to be a difference between location.href and the non-standard and deprecated document.location that had to do with redirection, but that is really last millennium.
For documentation purposes I would use window.location.reload() because that is what you want to do.
As said, modifying the href when there is a hash (#) in the url would not reload the page. Thus, I use this to reload it instead of regular expressions:
if (!window.location.hash) {
window.location.href = window.location.href;
} else {
window.location.reload();
}
Came across this question researching some aberrant behavior in IE, specifically IE9, didn't check older versions. It seems
window.location.reload();
results in a refresh that blanks out the entire screen for a second, where as
window.location = document.URL;
refreshes the page much more quickly, almost imperceptibly.
Doing a bit more research, and some experimentation with fiddler, it seems that window.location.reload() will bypass the cache and reload from the server regardless if you pass the boolean with it or not, this includes getting all of your assets (images, scripts, style sheets, etc) again. So if you just want the page to refresh the HTML, the window.location = document.URL will return much quicker and with less traffic.
A difference in behavior between browsers is that when IE9 uses the reload method it clears the visible page and seemingly rebuilds it from scratch, where FF and chrome wait till they get the new assets and rebuild them if they are different.
A difference in Firefox (12.0) is that on a page rendered from a POST, reload() will pop up a warning and do a re-post, while a URL assignment will do a GET.
Google Chrome does a GET for both.
Using JSF, I'm now having the issue with refresh after session is expired: PrimeFaces ViewExpiredException after page reload and with some investigation I have found one difference in FireFox:
Calling window.location.reload() works like clicking refresh icon on FF, it adds the line
Cache-Control max-age=0
while setting window.location.href works like pressing ENTER in URL line, it does not send that line.
Though both are sent as GET, the first (reload) is restoring the previous data and the application is in inconsistent state.
No, there shouldn't be. However, it's possible there is differences in some browsers, so either (or neither) may not work in some case.
from my experience of about 3 years, i could not find any difference...
edit : yes, as one of them here has said, only passing a boolean parameter to window.location.reload() is the difference.
if you pass true, then the browser loads a fresh page,
but if false, then the cache version is loaded...
In our case we just want to reload the page in webview and for some reasons we couldn't find out why!
We try almost every solution that has been on the web, but stuck with no reloading using location.reload() or alternative solutions like window.location.reload(),
location.reload(true), ...!
Here is our simple solution :
Just use a < a > tag with the empty "href" attribution value like this :
< a href="" ...>Click Me</a>
(in some cases you have to use "return true" on click of the target to trigger reload)
For more information check out this question :
Is an empty href valid?
window.location.href, this as saved my life in webview from Android 5.1. The page don't reload with location.reload() in this version from Android.
How can I reload the page using JavaScript?
I need a method that works in all browsers.
JavaScript 1.2 and newer
window.location.reload();
// If we needed to force the document to be fetched from the
// web server again (such as where the document contents
// change dynamically but cache control headers are not
// configured properly), Firefox supports a non-standard
// parameter that can be set to true to bypass the cache:
//window.location.reload(true);
JavaScript 1.1
window.location.replace(window.location.pathname + window.location.search + window.location.hash);
// does not create a history entry
JavaScript 1.0
window.location.href = window.location.pathname + window.location.search + window.location.hash;
// creates a history entry
location.reload();
See this MDN page for more information.
If you are refreshing after an onclick then you'll need to return false directly after
location.reload();
return false;
I was looking for some information regarding reloads on pages retrieved with POST requests, such as after submitting a method="post" form.
To reload the page keeping the POST data, use:
window.location.reload();
To reload the page discarding the POST data (perform a GET request), use:
window.location.href = window.location.href;
Hopefully this can help others looking for the same information.
You can perform this task using window.location.reload();. As there are many ways to do this but I think it is the appropriate way to reload the same document with JavaScript. Here is the explanation
JavaScript window.location object can be used
to get current page address (URL)
to redirect the browser to another page
to reload the same page
window: in JavaScript represents an open window in a browser.
location: in JavaScript holds information about current URL.
The location object is like a fragment of the window object and is called up through the window.location property.
location object has three methods:
assign(): used to load a new document
reload(): used to reload current document
replace(): used to replace current document with a new one
So here we need to use reload(), because it can help us in reloading the same document.
So use it like window.location.reload();.
Online demo on jsfiddle
To ask your browser to retrieve the page directly from the server not from the cache, you can pass a true parameter to location.reload(). This method is compatible with all major browsers, including IE, Chrome, Firefox, Safari, Opera.
Try:
window.location.reload(true);
The parameter set to 'true' reloads a fresh copy from the server. Leaving it out will serve the page from cache.
More information can be found at MSDN and in the Mozilla documentation.
This works for me:
function refresh() {
setTimeout(function () {
location.reload()
}, 100);
}
http://jsfiddle.net/umerqureshi/znruyzop/
To reload a page using JavaScript, use:
window.location.reload();
If you put
window.location.reload(true);
at the beginning of your page with no other condition qualifying why that code runs, the page will load and then continue to reload itself until you close your browser.
location.href = location.href;
Shortest (more)
history.go()
This should work:
window.location.href = window.location.href.split( '#' )[0];
or
var x = window.location.href;
x = x.split( '#' );
window.location.href = x[0];
I prefer this for the following reasons:
Removes the part after the #, ensuring the page reloads on browsers that won't reload content that has it.
It doesn't ask you if want to repost last content if you recently submit a form.
It should work even on most recent browsers. Tested on Lasted Firefox and Chrome.
Alternatively, you may use the most recent official method for this task
window.location.reload()
The Javascript reload() method is used to reload the current document or URL. The javascript location.reload(true) method work just like reload button in your browser. By default, the JS reload() method reloads the page from the cache, however you may force it to reload the page from the server side by setting the forceGet parameter to true: location. reload(true).
Source: https://www.coderepublics.com/JavaScript/javascript-location-reload-true.php
What about Depricated?
It is only the reload with forcedReload which is now deprecated. But to avoid depricated error you can use location.reload() without the forceReload flag.