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.
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 recently ran into an issue when preparing a web app to work in IE11. I've found a working solution but I would prefer to have a good reason why it worked rather than a guess.
My issue was an incorrect path when redirecting from the URL (http: //localhost:4724/View/Completion) to an exit page using the following javascript:
window.location = "Exit.aspx?timeout=true";
This resulted in a URL like so in IE11. Note the extra /View/:
http: //localhost:4724/View/Exit.aspx?timeout=true
In Chrome it results in the correct URL of:
http: //localhost:4724/Exit.aspx?timeout=true
I was able to correct the issue by including a forward slash when using window.location like so:
window.location = "/Exit.aspx?timeout=true";
Then it correctly routes Chrome and IE11 to the URL of:
http ://localhost:4724/Exit.aspx?timeout=true
What is IE11 interpreting differently when I include the forward slash for the window.location string?
A leading slash indicates an absolute path, i.e. a path relative to the root of the website. Without the leading slash the path is relative to the current URL.
Why it behaves differently in different browsers I can not say.
When I open a url with special characters using window.location, it seems to percent encode the special characters and then opens the URL. For example
var url = "http://gramfeed.com/instagram/tags/kühl";
window.location = url;
This will result in opening a page with URL:
http://gramfeed.com/instagram/tags/k%C3%BChl
instead of:
http://gramfeed.com/instagram/tags/kühl
How do I make the URL open correctly without percent encoded characters
Here is a jsfiddle to play with the code:
http://jsfiddle.net/krisrak/aSkMR/
I do not believe the problem is with windows.location and your JavaScript. The problems is rather with how gramfeed.com interprets tags. Try this in your code:
var url = "https://www.google.com/search?q=kühl"
window.location = url;
See that special characters stay unconverted.
Now try typing http://gramfeed.com/instagram/tags/kühl directly in browser address bar - the URL gets converted.
I also came across this issue but it was an entirely different problem, although the symptoms were the same. In the end it turned out I was redirecting to a desktop website URL but for mobiles this got redirected on their server to their mobile site and it was then that it got encoded twice.
So it's always worth trying to redirect to the mobile site directly if possible and on mobile.
Hope this helps someone else :)
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.
I have a problem with a link containing Chinese characters that is send to a javascript file in Internet Explorer. Generally that link is created by PHP and looks like this in IE:
www.example.com/%E6%B7%AC%E7%81%AB%E6%B2%B9_ASIN5034CN.pdf
In firefox it looks like this:
www.example.com/淬火油_ASIN5034CN.pdf
Both work in that direct way. I need to pass that link to a javascript that popups on the page and it will be displayed after the user entered her/his contact information.
This also works on firefox and other browsers but in IE that link is transfered to this which does not work anymore:
www.example.com/æ·¬ç«æ²¹_ASIN5034CN.pdf
I tried to do some encoding on it with encodeURIComponent but still no success. So the link is passed correctly to the javascript but it is totally screwed up only by IE.
Thx for any advice on that problem.
I found a solution that works. By encoding on the server side with PHP function urlencode the link works on javascript in IE.