top.document.location.href property behaviour in IE(8/9)

Question

I have a piece of code which works in a way that is unexpected to me. Let me first put down the details, so the code looks more or less like this:

window.onunload = doUnload;
var unLoadTimer;
var gInvokeOnBeforeUnload = true;
function setInvokeOnBeforeUnload() { gInvokeOnBeforeUnload = false; }

function doUnload() {
if(gInvokeOnBeforeUnload==true){
    setInvokeOnBeforeUnload();
    top.document.location.href = "LogOff";
    clearTimeout(unLoadTimer); 
}
//Function Midpoint
if (top.document.readyState != "complete" && gLogOffClick == false){
    unLoadTimer = setTimeout("doRealUnload("+func_call_count+")", 800); 
    //its just a timeout for the function to be called again
}
}

How I also added logging but for sake of keeping code small excluded from examples. The issue I faced was that top.document.location.href is NOT reassigned to "LogOff" and is still equal to the very first starting page I opened on the site, call it "LogIn".

To trigger the window.onunload event I hit F5 (and it happens all the time), but the logoff is not assigned to location.href. Only if at "//Function Midpoint" comment marker I add a simple alert(1); then logoff is triggered (as seen in Apache logs below), however location href is still the same as it was - "LogIn". Am I wrong to assume it should change as soon as its assigned a value?

And so I'm failing to understand several points:

Why location.href is not changed as soon as I assign it the value of LOGOFF.
What should happen as soon as LOCATION.HREF is changed
How does LOCATION.HREF get initialized when I open the browser and logon

Don't have any fancy session tracking mechanisms, its a straight forward HTML page with the above JS triggered @ onunload via F5.

All I want to achieve is to understand what happens behind the scenes and why the redirect happens if there is an alert(1); inbetween and doesn't if no break is there. In my case Apache registered the following:

With timeout:

IP.IP.IP.IP - xxx [28/Oct/2011:10:38:50] "GET /LogOff HTTP/1.1" 200 208
IP.IP.IP.IP - xxx [28/Oct/2011:10:38:50] "GET /LogIn HTTP/1.1" 401 540
IP.IP.IP.IP - xxx [28/Oct/2011:10:38:52] "GET /LogIn HTTP/1.1" 200 2898

Without timeout:

IP.IP.IP.IP - xxx [28/Oct/2011:10:41:04] "GET /LogIn HTTP/1.1" 200 2726

Any help or guidance towards what to read/where to look is appreciated, even better if someone could elaborate what happens behind the scenes. Im afraid I'm not well educated in JS engines, to my disadvantage. The code is also not really mine :(

If you have extra question I'm listening, maybe I omitted something important there :)

Didn't try to test in other browsers as IE is the only focus group I need...

score 0 · Accepted Answer · edited May 23 '17 at 09:59

0

document.location.href is read-only when unloading the page. Hence you are not allowed to change this property when the user wants to leave the page. This is a security 'feature'.

See also: Changing window.location.href in Firefox in response to an onunload event

I suggest you instead make an asynchronous call to the server, logging out the user etc. You can do this with an Ajax-call, which is fairly simple using jQuery.

edited May 23 '17 at 09:59

Community

1
1

answered Nov 03 '11 at 12:15

Alex

2,011
3
21
27

Thanks, I'll give the article a go. And will have to code it myself, jquery unfortunately is also not an option :) – guesXy Nov 03 '11 at 13:16
No problem. Please mark my answer as accepted if you find it sufficient in regard to your problem... ;) Happy coding! – Alex Nov 03 '11 at 13:19
Sure thing. One other question, would you know which spec could've reconfirm this? Not an MDN article but rather some W3C DOM spec? Tried googling for it, wasnt so lucky as I would want it to be. Also managed to redirect when using location.repalce but also moving it from onunload to onbeforeunload, but then again this might be a bad design decision :) – guesXy Nov 04 '11 at 14:56
I cannot find a piece of documentation that specifies exactly which elements are allowed as child elements, but the use of child elements in IFRAMEs should be clear from the example shown here: https://developer.mozilla.org/en/HTML/Element/iframe. In the HTML5 specification it says that "Descendants of iframe elements represent nothing. (In legacy user agents that do not support iframe elements, the contents would be parsed as markup that could act as fallback content.)" (http://www.w3.org/TR/html5/the-iframe-element.html#the-iframe-element) – Alex Nov 04 '11 at 20:14

top.document.location.href property behaviour in IE(8/9)

1 Answers1