何时需要使用window.opener.closed属性？opener窗口关闭后window.opener仍可访问的场景是否存在？

Hey there, great question about this often-overlooked browser API detail—let’s break it down clearly so you know exactly when and why to use window.opener.closed.

First, let’s address your core confusion: Yes, there are scenarios where the opener window is definitely closed, but window.opener still exists as an accessible object (so you need to check its closed property to confirm the state).

When window.opener Doesn’t Turn Null After Opener Closes #

In most modern browsers, closing the opener window will set the child window’s window.opener to null immediately. But there are exceptions where this doesn’t happen:

• Legacy browsers: Older versions of IE (11 and earlier) don’t null out window.opener when the parent closes. Instead, they leave a "dead" window object where all properties except closed throw errors if you try to access them.
• Specific modern browser behaviors: In some cases (like when the opener and child are same-origin, or when the child was opened without rel="noopener"), browsers might retain a proxy object for window.opener even after the parent closes. This object won’t let you interact with the parent’s DOM or run code, but it will let you check the closed property to confirm the parent’s state.

Scenarios Where You Must Use window.opener.closed #

There are three key situations where relying solely on checking if window.opener is null isn’t enough—you need to use the closed property:

1. Prevent errors when interacting with the opener
   If you’re building a child window that needs to call methods on the opener (like updating its DOM or sending data), you can’t just check if (window.opener)—because a dead proxy object might still exist. Instead, use:

   if (window.opener && !window.opener.closed) {
     // Safe to interact with the opener here
     window.opener.updateParentUI();
   }
   

   This ensures you only act when the opener is actually alive and accessible.

2. Cross-window communication reliability
   When using postMessage between child and opener, sending a message to a closed opener won’t throw an error, but it also won’t be received. Checking window.opener.closed first lets you avoid unnecessary message sends or handle the closed state gracefully (like showing a "Parent window closed" message to the user).

3. Handling user-initiated opener closures
   If the user manually closes the opener window (instead of it being closed via code), some browsers might not immediately null out window.opener. In this case, the only way to reliably detect the closure is to check the closed property—especially if your child window needs to adjust its behavior (e.g., disable features that depend on the parent).

Quick Recap #

• Always check window.opener exists first (to avoid null errors), then verify !window.opener.closed to confirm the opener is alive.
• Use closed when you need absolute certainty about the opener’s state, especially in legacy browser environments or when dealing with user-initiated closures.

内容的提问来源于stack exchange，提问作者Anton