考慮以下情況：
- 第 1 步：網站 A 在新選項卡中打開網站 B（此時網站 B 有其打開器視窗參考，即 window.opener 中的網站 A 視窗物件）。
- 第 2 步：網站 B 重定向到網站 C（我們在這里也有 window.opener 參考網站 A 視窗）。
- 第 3 步：然后網站 C 執行一些身份驗證并重定向回網站 B。在第 3 步中，window.opener 具有當前視窗物件的參考，即網站 B 本身的視窗物件（window.opener === 視窗），我們'已經失去了對原始開啟器的參考（即網站 A 視窗物件）。我們需要 window.opener 物件來使用 postMessage 與網站 A 進行通信。
步驟的視覺再現
注意：我們無法控制網站 C，也無法控制它們如何重定向回網站 B。這僅在 Firefox/Safari 上發生。在 Chrome 上，我們能夠在重定向后獲得原始的開啟者參考。
如果網站 C 使用 rel=noopener 進行重定向，則 window.opener 應該為空（來自 MDN 的參考）。我無法理解在哪種情況下 window.opener 可以是當前視窗物件以及為什么它發生在 Firefox/Safari 而不是 Chrome 上？除了網站 C，我們還能在任何地方做些什么來防止這種情況發生嗎？
uj5u.com熱心網友回復：
這在 Firefox 和 Safari 中是可能的，添加 target 時 window.opener 可以是當前視窗_self。如果這樣做，window.open('someurl', '_self')則 window.opener 將是當前視窗，并將在同一選項卡而不是新選項卡中打開。這只發生在 safari 和 firefox 中（據我觀察）。在任何情況下，所有基于 Chromium 的瀏覽器都不會更改原始的開窗器。
我不知道 safari 和 firefox 以這種方式處理它的確切原因，我試圖找到原因但找不到。
我曾經遇到過這個問題，我們所做的解決方案是要求網站 C 使用window.location.replace或window.location.href重定向回網站 B，以便他們在同一個選項卡中打開網站 b。
轉載請註明出處，本文鏈接：https://www.uj5u.com/ruanti/426740.html
標籤：javascript html 火狐