遷移至 Manifest V3 的已知問題

我們最近宣布 Manifest V2 淘汰時間表的異動事項，雖然我們持續致力於採用 Manifest V3，也瞭解我們還有許多進步空間。

  • 在宣布新的淘汰時程之前，我們現已解決平台優先性方面的缺漏問題，並解決了本頁提及的重大錯誤。
  • 我們為開發人員預留了建構時間，保證從時間表公告發布到待移除 Manifest V2 的實驗至少六個月。

消弭平台落差

我們致力於消弭以下缺口，然後宣布推出新的 Manifest V2 淘汰時程：

我們根據合作夥伴、錯誤報告和開發人員的意見收集問題。我們會持續努力改善擴充功能平台的穩定性和整體效能。

目前尚無待解決的問題是重大平台缺口。

以下問題最近已解決：

  1. 支援 ChromeOS 的檔案處理功能，以取代 chrome.fileBrowserHandler [Chrome 120]。
  2. 使用者指令碼支援：允許使用新的 userScripts API [Chrome 120] 以任意程式碼註冊內容指令碼。
  3. 特定作業處理時間超過五分鐘的額外強大 Service Worker 保持運作。
    • 已在 Chrome 116 中新增 permissions.request()、desktopCapture.chooseDesktopMedia()、identity.launchWebAuthFlow() 和 management.uninstall()。
    • 已在 Chrome 118 中新增至 chrome.debugger
  4. 增加宣告式網路要求 (DNR) 的靜態和啟用規則集數量。啟用的靜態規則集數量從 10 個增加至 50 個，而靜態規則集總數從 50 個增加至 100 個 [Chrome 120]。
  5. 擴充畫面外文件功能，方便使用者使用畫面外文件。已在 Chrome 116 版中新增 GEOLOCATION。
  6. 改善 chrome.tabCapture API 支援 [Chrome 116]：
    • 支援從 Service Worker 呼叫 getMediaStreamId()。
    • 支援在畫面外文件中從串流 ID 取得 MediaStream。
  7. 在同時啟用 WebSocket 連線的情況下延長 Service Worker 的生命週期 [Chrome 116]。

Manifest V3 常見問題

問：我們計劃支援永久服務工作人員嗎？
答：從背景指令碼遷移至 Service Worker 的其中一個重要原因，是事件導向的程式設計模型 (事件導向的程式設計模型) 的暫時性質來自服務工作站的暫時性質。因此，我們不打算為長期提供服務的工作者提供支援。不過，為瞭解決擴充功能開發人員的具體需求，我們會持續改善服務工作處理程序。請特別注意以下幾點：

  • 所有擴充功能事件和 API 呼叫都會延長服務工作站生命週期。
  • 選取的用途 (例如原生訊息傳遞) 可讓擴充功能服務工作處理程序持續超過 5 分鐘。

問：我可以在服務工作處理程序中存取 DOM 嗎？
答：我們採用網路平台採取的方法，不在網路工作站 (包含 Service Worker) 中納入 DOM 存取權。為了支援需要服務工作人員背景 DOM 存取權的用途，我們推出了一項功能，讓您將背景工作委派給可使用完整 DOM 存取權的短期「畫面外文件」。

問：Manifest V3 中是否有辦法支援遠端程式碼？
答：為提升 Chrome 擴充功能的安全性，我們將繼續禁止在 Chrome 擴充功能中執行任意遠端代管的程式碼。不過，這不代表我們不允許任何類型的動態程式碼執行。不過，我們仍支援在 Chrome 擴充功能中動態執行程式碼的不同選項：

問：Manifest V3 不支援我的 Manifest V2 擴充功能採用 webRequestBlocking。如何繼續在 Manifest V3 中提供相同功能？
答：我們相信新的 declarativeNetRequest API 可以解決大多數的要求封鎖用途，這麼做的好處是可避免處理序間通訊、在每次要求執行程式碼，或是在提出要求時需要有效的擴充程序。不過，如果是複雜的企業 (或教育) 用途，系統仍支援動態要求封鎖功能。

有漏網之魚嗎？請告訴我們。