3

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?

Daniel A. White
  • 187,200
  • 47
  • 362
  • 445
Cellivar
  • 568
  • 10
  • 27
  • 1
    Uhm... lemme think... because JavaScript developers decided like so. Your question is the same as asking "Why facebook logo is blue?". – Marco Bonelli Aug 07 '14 at 18:46
  • 1
    I guess it's just a convention and something we as developers have to be aware of. If you made it 'null' instead, then someone might ask why it wasn't made 'undefined' . I guess it came down to just picking one option :-) – TGH Aug 07 '14 at 18:48
  • 2
    @MarcoBonelli Well yeah, but *why*? With C# you can pull up just about every design decision through history and I can find scarce little on questions like this. – Cellivar Aug 07 '14 at 18:51
  • I guess one question is why not? You can quite easily do `if(window.parent === window)` to check if its the same instance, but you've saved yourself `if(window.parent) { // Do Something }` with the rest of your code. – Ian Aug 07 '14 at 18:54
  • 1
    If I'm going through the parents in a loop in almost any other language, the top level element will either not have a parent property, or the parent property would be set to null. JavaScript doesn't follow this approach, instead they decided circular top references were a better idea. I understand that workarounds exist, but I'm wondering why the implementation was circular instead of having a definitive end. – Cellivar Aug 07 '14 at 18:56
  • @MrDoom: DOM was not "designed". Microsoft and Netscape *just implemented it*. And what they did became standard, because everything else would've broken the web. – Bergi Aug 07 '14 at 21:28

3 Answers3

0

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.

  • 1
    From within the iframe, Bob will call window.parent and get the containing element. From there, Bob will call window.parent and get the containing element. From there, Bob will call window.parent and get the containing element. I guess I don't see the utility of that over simply saying the parent of the global object is undefined. Perhaps I'm just stuck in the thinking of C++/C#, where "null/undefined" is a very valid answer for more than just data that hasn't been initialized. – Cellivar Aug 08 '14 at 12:59
  • To get the href is simply window.parent.location.href, works whether the page is in an iframe or not. Easier than (window.parent || window).location.href – Quentin 2 Aug 13 '18 at 08:21
0

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.

jumpdart
  • 1,702
  • 16
  • 35
  • This is no fair reason. Dev's could simply do `window.parent && window.parent.doSomeCall()` instead of `window.parent.doSomeCall()` that would be safer IMHO. – Izhar Aazmi May 14 '20 at 12:58
  • @IzharAazmi What I meant was that if you had an html page that wanted to communicate outside of itself upward, you might want window parent to exist even if it self references so that you dont need to know about your implementation context to be able to send messages/events. Becuase how that html is loaded, determines where the final window.parent might be – jumpdart May 15 '20 at 13:46
  • but yes it wouldnt be that hard to implement a null check at your top level to account for it to make it handle each case. It was just an instance that I ran across where the functionality was beneficial. And i dont remember the specifics but I do remember ther being some funny behavior with window.top and window.parent that made the self referencing window.parent at the top helpful. – jumpdart May 15 '20 at 14:08
0

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.

Panu Logic
  • 2,193
  • 1
  • 17
  • 21