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 :)
Related
I'm very new to JavaScript so I might did not get the basics right.
I'm trying to open a new page based on the currents page URL. But it seems that the function has no reference to the current URL.
It should be a simple Firefox Addon that looks at the URL, replaces a certain part and opens the "new" page in a new tap.
browser.browserAction.onClicked.addListener(function() {
var path = window.location.href
var newPath = path.replace('www', 'test')
var creating = browser.tabs.create({
"url": "${newPath}"
});
});
Being on www.google.com it should open me a new tap with test.google.com. Instead it opens me a Tab with the following URL=moz-extension://fde3def8-cf60-4536-b96b-1bf7ed91a8da/$%7BnewPath%7D.
Taking a look at the end of the URL I think it has no reference to the variable. When replacing the newPath variable in the last line with a static sample URL e.g. www.facebook.com it works fine.
Extension pages, such as an extension pop-up page, are separate pages. They run in a separate context that has no (or very little) connection to the regular currently open page.
Your path is the URL of the extension, which apparently happens to be "moz-extension://fde3def8-cf60-4536-b96b-1bf7ed91a8da/". You are trying to replace parts of that URL and open the result in a new tab.
Read up on architecture of extensions first:
Anatomy of an extension
Achitecture of extensions (for Chrome, but the concept is the
same)
To accomplish what you are trying to do, you will probably have to first query the active tab using tabs.query({active: true}) to get its URL.
Note on asynchronous execution:
Many extension related APIs (including tabs.query) are asynchronous (promise-based in Firefox). Promises might be a bit difficult to grasp for beginers.
You also confuse strings and template strings:
This is also incorrect: "url": "${newPath}". It should be simply "url": newPath. You seem to be confusing regular strings with template strings.
String interpolation in JS works only with backticks not with quotation marks as in: "url": `${newPath}`
This is my js window.open() code.
var url = "https://www.google.com"
window.open(url, "_blank", "menubar=no,location=yes,resizable=yes,scrollbars=yes,status=yes,width=640,height=480", false);
It opens a new browser window with the "url" as expected.
But the issue is that, it also changes the current url in my main web application.
For example before my window.open() call if I was on this url:
https://example.com/#!/projects/56asda/view
After the call the url redirects to this:
https://example.com/#!/
How can this issue be prevented? I have not found any solution for this on the internet.
I am using angularjs 1.0 for my frontend.
Please refrain from answering that "_blank" should work etc.
Any help will be invaluable.
I have tried to duplicate your issue but I have found no issues while executing the code which would mean your issue might be related to your web server settings.
Anyways, have you tried calling it like this:
var url = "https://yourlink.here";
window.open(url, "_blank");
Without anything like "menubar=no" or other arguments?
If you haven't, I suggest you do and if that works, just add the arguments one by one to check which one contains the error.
One of our partner sites has a webpage with a form where I enter 2-3 number fields, a captcha and then submit the form. It opens a pop-up showing the requested details.
The pop-up url is something like this
https://abc.co/xyz/gef/sample/certificate?Values=123456789|2011|A1563894a|y6zs8v|'1373550','4148114'
This thing works fine only in IE.
The same process doesn't work in Chrome or Firefox, because the ' in the url is encoded to something like this
https://abc.co/xyz/gef/sample/certificate?Values=123456789|2011|A1563894a|y6zs8v|%271373550%27,%274148114%27
I am shown an error
We are unable to process your request. Please try again later or contact Admin for further details. Try Again with Proper Inputs
So, basically the server side decoding is set right and as an end user, I am forced to use IE which sucks!
The form action happens is written in Javascript, which I can edit before the post request. Sample code:
var logNo =123456789;
var url ="/xyz/gef/sample/certificate";
var fromYear = "2011";
var logId="A1563894a";
var textID="y6zs8v";
var logNoListForCert="'1373550','4148114'";
var selectedValues =logNo+'|'+fromYear+'|'+logId+'|'+textID+'|'+logNoListForCert;
window.open('/xyz/gef/sample/certificate?selectedValues='+selectedValues,"Log_Certificate","scrollbars=yes,resizable=yes,height=500,left=0, top=0,alwaysRaised=1");
So, is there a way I can disable the encoding in Chrome & Firefox or any other workaround for this to work.
Thanks :)
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.
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.