WebDriver BiDi 下載事件新增 downloadResponse 欄位，補上完整 HTTP 回應
github.com (whatwg/html) · 2026-09-08
2026-09-08，WHATWG HTML 標準原始檔在 commit b3dbeee6c0cb07178f48d7c34e260f5e0d24060e 中修改三處演算法文字，讓 WebDriver BiDi 的下載事件狀態物件多帶一個 downloadResponse 欄位，用來夾帶觸發該次下載的 HTTP 回應物件。這次修改對應 w3c/webdriver-bidi PR #1117，該 PR 同時替下載事件加上 downloadId，用來在缺少 navigation id 時仍能配對事件先後順序。
背景：WebDriver BiDi 的下載事件
WebDriver BiDi 是傳統 WebDriver（HTTP 命令式）之後的雙向協定後繼者，改用事件推播讓自動化工具即時掌握瀏覽器狀態。下載相關事件屬於 browsingContext 模組，包含下載開始時觸發的 downloadWillBegin，以及下載結束（完成或取消）時觸發的 downloadEnd。在此次修改前，這些事件的狀態物件只帶有 status（進行中／取消／完成等列舉值）、url 與 suggestedFilename，測試框架無法得知觸發下載的伺服器實際回了什麼 HTTP 回應。
PR #1117 的作者說明，新增 downloadId 是為了「在 navigation id 缺席時，仍能把 downloadWillBegin 和 downloadEnd 兩個事件配對起來」，同時也為後續讓命令能操作下載（例如取消特定下載）鋪路。本次 HTML 規格的修改則是這個提案在 spec 端落地的一半：把 response 物件塞進事件狀態演算法裡。
核心改動
commit 在三個地方做了幾乎相同的文字修改：把敘述句尾的句號改成逗號，再接上一句新增條件。以其中一處（下載開始時的 navigation 狀態）為例，改動後的敘述大致是：
status is "in progress", url is url, and suggestedFilename is filename
→ status is "in progress", url is url, suggestedFilename is filename,
and downloadResponse is response.另外兩處分別對應下載被取消（canceled）與下載完成（downloaded）兩種終態，套用相同模式補上 downloadResponse is response。整個 commit 只增刪各 4-7 行，屬於精準的欄位新增，不涉及演算法流程改動。
影響範圍
- 受影響事件：
browsingContext.downloadWillBegin、browsingContext.downloadEnd - 新增欄位：三種下載狀態（進行中、取消、完成）皆新增
downloadResponse - 搭配
downloadId使用時，測試框架可在單一分頁觸發多個並行下載的情境下正確配對事件
對 Selenium 4、Playwright 等已支援 BiDi 後端的自動化框架而言，這代表可以直接從事件讀出下載回應的標頭與狀態碼，用來驗證 Content-Disposition、MIME type 是否正確，而不必額外攔截網路層。
原始來源：WHATWG HTML commit b3dbeee6、w3c/webdriver-bidi PR #1117
瀏覽器介面觸發的同網址導覽改採 replace 語意，收斂三大引擎不一致行為
github.com (whatwg/html) · 2026-09-08
2026-09-08，WHATWG HTML 標準在 commit 3e7b72c44ce144cee7db859cd0647af6646b6793 修改導覽演算法中 history handling 為 "auto" 時的判斷條件，讓使用者透過瀏覽器介面（網址列、重新整理鍵等）導覽到目前分頁的相同 URL 時一律採用 "replace" 語意。此修改對應 issue #12803，回報者指出舊規格文字「和任何一個瀏覽器引擎的實際行為都對不上」。
背景：replace／push 與 userInvolvement
HTML 的 session history 導覽有兩種寫入方式：push 會新增一筆歷史紀錄（history.length 增加），replace 則覆蓋目前這筆。此外，Navigation API 的 navigate 事件會帶一個 userInvolvement 屬性，標示這次導覽是否由使用者操作瀏覽器介面觸發（例如在網址列按 Enter、按上一頁／下一頁），還是純粹由頁面內腳本或連結啟動。
issue #12803 指出三方行為互不相同：Firefox 與 Safari 不會增加 history.length，卻回報 navigationType 為 "push"；Chromium 同樣不增加長度，卻回報 "replace"；而規格當時要求的是 "push"，等於三家都對不上。問題根源在於：從網址列重新整理同一頁時，initiatorOriginSnapshot 通常是不透明（opaque）來源，不滿足舊條件裡「與目前文件同源」的要求，因而落入預設的 push 分支。
核心改動
修改前後的判斷條件差異如下（節錄自 "auto" 分支）：
- If url equals navigable's active document's URL, and
- initiatorOriginSnapshot is same origin with navigable's
- active document's origin, then set historyHandling to "replace"
+ If url equals navigable's active document's URL, and either
+ userInvolvement is "browser UI" or initiatorOriginSnapshot is
+ same origin with navigable's active document's origin,
+ then set historyHandling to "replace"也就是把原本單一的「同源」條件，改成「瀏覽器介面觸發」或「同源」兩者滿足其一即可，讓網址列重新整理、書籤點擊等場景不再需要靠來源判斷才能落入 replace 分支。這與 Chromium 既有且行為自洽的實作對齊，也和 WebDriver 觸發同 URL 導覽時既有的 replace 處理方式一致。
影響範圍
- 受影響演算法：導覽演算法（navigate）中 history handling 為
"auto"的判斷分支 - 受影響 API：Navigation API 的
navigate事件navigationType屬性、history.length的一致性 - 受影響場景：網址列重新整理、書籤導覽等「使用者操作瀏覽器介面、目的地與目前頁面同 URL」的情況
對監聽 window.navigation 的 navigate 事件、依賴 navigationType 判斷是否為「重新整理」的網頁應用而言，三大引擎收斂到同一套 replace 語意後，這類判斷邏輯終於能寫出跨瀏覽器一致的程式碼。
HTML 規格編輯性修正：closed getter 的敘述改回指向 navigable
github.com (whatwg/html) · 2026-09-08
2026-09-08，WHATWG HTML commit 8293d5e1f775e38044a83946c477aa4091220499 修正 Window 物件 closed getter 演算法裡一處過時用語，把「this's browsing context」改為「this's navigable」。作者為 shannonbooth，由 annevk 提交，是一次不改變任何瀏覽器實作行為的編輯性（editorial）修正，讓文字與現行規格模型保持一致。
背景：從 browsing context 到 navigable 的重構
WHATWG 在 2022 年的 navigable 重構（PR #6315）中，把舊有「browsing context」這個把視窗容器與 session history 緊密綁在一起的抽象，拆解成獨立的 navigable 概念，讓文件容器與歷史紀錄項目分離，藉此更乾淨地處理同文件導覽、bfcache 還原、iframe 置換等情境。重構之後，規格全文的敘述被逐段從「browsing context」遷移為「navigable」，但這類大規模替換難免留下零星漏網之魚，需要日後陸續以編輯性 commit 補上。這次修正的 closed getter 就是其中一處。
核心改動
整份修改只有一行加、一行刪，落在 closed getter 演算法的條件句上：
- steps are to return true if this's browsing context
- is null or its is closing is true; otherwise false.
+ steps are to return true if this's navigable
+ is null or its is closing is true; otherwise false.完整敘述因此變成：「closed getter 的步驟是，如果 this 的 navigable 為 null，或其 is closing 為 true，則回傳 true；否則回傳 false」。這裡的 is closing 是掛在 navigable 物件上的旗標，會在分頁／視窗被關閉、或呼叫 window.close() 之後設為 true，語意本身完全沒變，只是把指涉的物件從舊概念換成現行概念。
影響範圍
由於只是把已經無效的舊術語替換掉，此修改不影響任何瀏覽器的 window.closed 實作行為，也不會反映在 Web 開發者可觀察到的任何 API 表現上。它的意義在於維護規格文字本身的準確性：如今「browsing context」一詞在規格裡已改為較窄義、多半只在歷史性或群組層級的描述中出現，若某段演算法仍寫著「this's browsing context」，很容易誤導閱讀規格、對照實作的工程師。這類逐步清理也是 navigable 重構完成數年後，WHATWG 編輯持續進行的收尾工作之一。