We Keep Coding

Getting the URL from the address bar

I have an iframe on mynewwebsite.com showing content from mywebsite.com
alert(window.location.hostname);
always shows mywebsite.com, is there any way I could get the URL from the user's address bar without modifying anything on mynewwebsite.com?
I want to check the domain and load stylesheets accordingly.

Try something like this
var url = (window.location != window.parent.location) ? document.referrer: document.location;

I think window object refers to the current window -- the iframe's window object because you're calling it from the iframe.
Try
window.parent.location.hostname
But since they are two different domain names you will encounter a cross-site-scripting security (aka XSS) limitation. You have to configure your servers to allow XSS between the two domains.

Maybe this will help:
alert(window.parent.location.hostname);
alert(window.top.location.hostname);
It works in Chrome like a charm.

var URL = window.location.href;

Try
var myIframe = document.getElementById('yourIframeId');
alert(myIframe.contentWindow.location.hostname);

window.location.href not working on IE

I have a problem with window.location.href.
I'm trying to redirect to a page with the following code:
window.location.href = "juego.html"+'?modoJuego='+modoJuego+"&etapa="+etapa+"&rango="+rango;
It works perfectly on Firefox and Chrome, however in IE10 the browser freezes and I have to restart it. Sometimes it redirect to the desired page, but the parameters do not pass through. I have been looking for a solution, for example this one:
Window.Location Not Working In IE?
But the proposed solution do not work for me.
Do somebody know how to deal with this?

The problem is likely due to the value of your variables. If they contain special or invalid characters, those needs to be passed through encodeURIComponent before being assigned to window.location.href.

For some reason IE only like full url.
I have te same problem and fix it adding the full url like this:
var baseURL = 'http://www.your_url.com/';
window.location.href = baseURL + "juego.html"+'?modoJuego='+modoJuego+"&etapa="+etapa+"&rango="+rango;

Use encodeURIComponent() to escape your url:
window.location.href = encodeURIComponent("juego.html?modoJuego=" + modoJuego + "&etapa=" + etapa + "&rango=" + rango);
Works fine on Firefox 23.0, Chrome 28.0.1500.95 and Internet Explorer 10.

Try window.location.replace(...) instead.
Refer this question for information:
How to redirect to another webpage in JavaScript/jQuery?

Forcing Javascript Redirection

I am trying to implement what seems to be very simple JavaScript redirection, via the following rudimentary command:
window.location.href = "http://www.somesite.com";
So far so good, it works. I also can do it via the following method:
location.replace("http://www.somesite.com");
No problem here, it works again! The problem comes when I loose the protocol out of the string:
window.location.href = "www.somesite.com";
OR:
location.replace("www.somesite.com");
It just appends the new location to the current url:
www.currentsite.com/www.somesite.com
Of cause, that's not what I want. Is there any way to force the redirect?

One way is to use protocol-relative url like this:
window.location = "//www.somesite.com";
Or
window.location = "//somesite.com";
This way, it would redirect and browser itself will take care of figuring out protocol part eg http or https
Working Example

The protocol is required.
How else would the browser know whether
location.replace("mysite.pl");
was going to a Polish website or a Perl script on the current website?

You could do something like this to add http:// to the URL if it's not already there... although I can't think of a reason for not just including it yourself. Why complicate things?
​function redirect(url) {
if(url.substr(4) != "http")
url = "http://" + url;
window.location.href = url;
}
redirect("www.google.com")
​

Webkit turning "#" into %23 causing 404 errors?

I'm just building a simple ajax site but running into a problem in safari and chrome. I'm just creating a simple redirect if the user goes to a page i.e.
"/blog"
they would be redirected to
"/#/blog"
code :
url = window.location.pathname
if(url != "/") {
window.location.pathname = "/#" + url
}
This is working great in FireFox but unfortunatly webkit browsers are turning the "#" into a "%23" and giving a 404, for example:
"/%23/blog"
How can I prevent this?
Thanks,
Alex

pathname refers to everything after the host, and before the query string and hash. Consider this instead:
window.location.hash = window.location.pathname;
window.location.pathname = "/";
I'm not exactly sure which browser(s) are implementing the JavaScript spec correctly, but WebKit's behavior seems correct to me.

You are setting pathname, which, by definition, does not include the hash. Webkit is trying to fix that for you (Firefox just made a better guess of what you wanted). Try this:
window.location = '/#/blog';

BASE HREF, javascript, and Internet Explorer vs. Firefox

Question:
IE and Firefox / Safari seem to deal differently with BASE HREF and Javascript window.location type requests. First, is this an accurate description of the problem? What's going on? And what's the best cross-browser solution to deal with this situation?
Context:
I have a small PHP flat file sitelet (it's actually a usability testing prototype).
I dynamically generate the BASE tag's HREF value in PHP, i.e. if it's running on our company's server, it's:
$basehref = 'http://www.example.com/alpha/bravo/UsabilityTest/';
and on my local dev machine, it's:
$basehref = 'http://ellen.local/delta/echo/foxtrot/UsabilityTest/';
For one of the tasks, I collect some user input, do some transformations on it in Javascript, and send to the server using code like this:
function allDone() {
// elided code for simplicity of stackoverflow question
var URI = "ProcessUserInput.php?";
URI = URI + "alphakeys=" + encodeURI( keys.join(",") );
URI = URI + "&sortedvalues=" + encodeURI( values.join(",") );
window.location = URI;
}
Both the javascript file (containing function allDone()) and the processing PHP script (ProcessUserInput.php) live in a subdirectory of UsabilityTest. In other words, their actual URL is
http://www.example.com/alpha/bravo/UsabilityTest/foxtrot/ProcessUserInput.php
aka
$basehref . '/foxtrot/ProcessUserInput.php'
The Problem
IE's JavaScript basically seems to ignore the BASE HREF. The javascript and the PHP processor live in the same directory, so the call to ProcessUserInput.php works out fine. The input gets processed and everything works fine.
But when I test on Firefox, the JavaScript does appear to use the BASE HREF, because the script's output gets sent to
$basehref . '/ProcessUserInput.php'
This breaks, because ProcessUserInput.php is in a subdirectory of basehref. However, if I add the subdirectory name to the javascript, it no longer works in IE.
Solutions?
I can think of a few ways to solve this:
In Javascript, read the HREF property of the BASE tag and manually prepend to var URI in the javascript, calling a fully-resolved absolute URL
Process the .js file with PHP and insert the $basehref variable into the script
Move the files around
Something else?
I'm sure there must be other ways to solve this too. What's the best way to deal with BASE HREF in JavaScript when IE and Firefox apply it differently in JavaScript?

Using the assign method of window.location seems like the most straightforward answer.
Instead of
window.location = URI;
I'm using this:
window.location.assign( URI );
which is doing the right thing in both IE and Firefox.

IE and Firefox / Safari seem to deal differently with BASE HREF and Javascript window.location type requests.
Yes, this is a long-standing difference going back to the early days of Netscape-vs-IE.
IE enforces base-href only at the point a document element is interacted-with. So, you can createElement('a'), set a relative href and click() it*, but the base-href will be ignored; appendChild it to the document containing the base-href, and it'll work.
On the other browsers the base-href is taken as global per-window and always applied. Which is right? It seems to be unspecified. The original JavaScript docs say only that location.hash (and hence, location applied as a string):
represents a complete URL
So setting it to a relative URL would seem to be an undefined operation.
(*: link.click() is a non-standard method supported by IE and Opera)
read the HREF property of the BASE tag and manually prepend
Probably what I'd do, yeah, if you're dead set on using <base>.

I believe you want to modify window.location.pathname, not window.location. window.location is a Location object, that has multiple variables. As a result, the effects of changing it is not well defined. However, window.location.pathname is defined as the path relative to the host, which is what you want.
If you want to read up more on the many variables you can change in window.location, I'd check here. According to Mozilla's documentation, changing any variable in window.location should reload the page with a new URL corresponding to those changes.

I had the same problem today, after some researching, couldn´t findn any way to override this issue in IE9, what is a requiremente for my project, so, i did the following approach (jquery based, but it´s really easy to make it in simple javascript).
href = function(url){
if ($("base").length > 0 ){
location.href= $("base").attr("href")+url;
}else{
location.href = url;
}
}
And then, change
location.href= 'emp/start'
to
href('emp/start');

just add $('base').attr('href') before the link. (using jquery) or
document.getElementBytagname('base').href

You can always use Vanilla JS :)
var href = document.getElementBytagname('base')[0].href
I hope this helps.