Why does window.parent self-reference?

Question

I understand from documentation and several related StackOverflow posts that window.parent, if there is no other parent, will self-reference and thus never be undefined.

I can't seem to find a decent reason as to why this is. JavaScript does have its idiosyncrasies, but this one just seems odd.

MSDN simply states that

If the current window doesn’t have a parent, i.e. it occupies the whole browser window, Parent returns the current window’s Window object.

MDN states

If a window does not have a parent, its parent property is a reference to itself.

And the W3 standard itself

The value of the parent attribute of a Window object MUST be the parent document's Window object or the document's Window object if there is no parent document

I've not seen other languages acting like this, what reason is there for this self-referencing design? Wouldn't 'null' or 'undefined' make for a more obvious situation when you hit the topmost element in a window?

So, why?

Answer 1

When working with iframes, developers often automate processes which navigate through windows. While the algorithms at their core will consist of the same basic logic, the conceptual approaches will differ.

Instead of working in a parent-children manner, sometimes the developer will craft the system in such a way that it will seem not to look for the parent, but simply for the right window to use. The one that controls (not necessarily holds) the area where the code is currently running.

In the case of such approaches, it would be conceptually weird for the program to return "false" or "undefined" when asking it a refference to the "right" window, because there must be one.

For instance, Bob is programming:

Bob: I embedded an iframe! Alright, let me just play around with the window that contains my entire iframe (not the window of the iframe itself)

Bob: What? Null? But I don't get it, my iframe is up & running, how can there not be any window which controls it?

I'm just saying that window.parent may not be meant to literally and strictly get the parent from the DOM (like .parentElement does), but more like to point to the window which absolutely wraps not only your script, but also everything else that wraps it at lower levels.

In the case of the topmost window (where your script is being executed), that statement may return the same window because, not having any oher window more important than it, it simply becomes 'the right one' to use when looking for the superior container.

I hope I make some sense.

Answer 2

I would say that this helps with window communication. When loading third party content, it might leverage window.parent.postMessage as it's form of communicating with it's implementation context, but it might be implemented with no parent window. An html page loading content in an iframe would have its own window as the iframe windows parent, but content loaded into something like a browser plugin such as an electron webview would have no parent window so the postmessage would fail and the implementing context would not be able to listen for that event. So basically it just allows for a safety net to allow devs to always be able to use window.parent because they might not know if their code will be running from window.top or not.

Answer 3

I assume this is just unfortunate naming. That property could have been better named something like 'parentOrCurrentWindow'.

If what you want is 'parent or current window' then being able to access that as just 'parent' makes your code a little shorter. And if you know that is so then it does not matter much. You could say it is better to get hold of SOME window than null.

But note this has nothing to do with JavaScript the language. This is about the DOM-model implemented by browsers. The DOM model could be improved to include two properties 'parentOrCurrent' and 'parentOrNull'. And in fact you could assign those variables in your own code to make it clear which one you are talking about.