大家好，我們是獨立開發團隊 TMETE。這篇想分享一個 Chrome 擴充功能的設計：當網站因分頁切換而暫停影片時，如何減少打斷，同時保留使用者自己按暫停的選擇？

專案資訊

• 專案名稱： NoPause Playback
• 開發狀態： 已上架，持續改善相容性；本文以目前 4.5.3 版本的實作設計為例。
• 解決的問題： 相容網站在切換分頁、最小化視窗、失去焦點等情境下，主動暫停原本正常播放的影片。
• 實際體驗： Chrome 線上應用程式商店。每個網站提供累計 20 次免費使用額度，超過後需付費。本文由開發者撰寫。

一、開發動機：查個資料，就得重新按播放

看教學時切換分頁做筆記，聽訪談時回覆訊息，或在主螢幕工作、把影片放在副螢幕，都是很自然的使用情境。但有些網站會把「沒有停留在播放器頁面」判定成應該暫停。

常見情境包含切換分頁、最小化瀏覽器、滑鼠離開頁面或螢幕、切換到其他應用程式，以及子母畫面（PiP）或雙螢幕使用時的焦點變化。另一些中斷可能來自計時器或閒置偵測；這類情況需要個別評估，不能認定都能用同一種方法處理。

從網站角度看，自動暫停可能是為了避免使用者錯過內容、降低無人觀看時的資源消耗，或配合觀看流程與營運規則。這些是一般可能性，並非我們確認過每個網站的商業動機。

對使用者而言，真正的需求是：想繼續聽的時候，不必一直回去按播放；真的按了暫停，也不要被工具擅自播回來。

二、先區分「不可見」與「失去焦點」

• visibilitychange：頁面的可見狀態改變，例如切換分頁。
• blur：視窗或元素失去焦點。在雙螢幕情境中，影片仍可能看得到，只是使用者正在另一個視窗操作。
• 滑鼠移出頁面：又是另一類訊號，不代表影片一定不可見，也不代表使用者要求暫停。

瀏覽器不會因為所有 blur 事件就一律暫停影片。部分網站會自行監聽這些訊號，再呼叫播放器的暫停邏輯。因此，診斷時要分清楚：是網站主動暫停、網路載入失敗，還是瀏覽器或作業系統已經限制背景工作？

三、技術架構：頁面層與擴充功能層分工

NoPause 使用 Manifest V3 與 JavaScript，主要分成以下幾個部分：

Chrome 的 content script 預設執行在隔離環境。它能操作頁面 DOM，但不等於與網站腳本共用所有 JavaScript 物件環境。若要處理網站自身對媒體方法的呼叫，就需要考慮 MAIN world 與隔離環境的分工。

目前實作在 document_start 載入頁面側腳本，再由擴充功能側依設定傳遞啟用狀態。提早載入是為了較早建立必要的監聽，不代表所有網站都應該一直啟用保護。

跨環境訊息也不應被視為可信的付費或權限憑證：頁面側能接觸的訊息與擴充功能的權限邊界，是不同層次的事情。

四、核心挑戰：這次暫停，是誰想要的？

最容易想到的做法，是一收到 pause 就呼叫 play()。但這樣使用者手動按暫停，也會被立刻恢復，體驗反而更糟。

目前的處理方式，是把幾種訊號一起看：

1. 媒體先前是否正在播放？ 已結束、沒有來源、已發生錯誤的媒體，不應直接恢復。
2. 最近是否出現背景或焦點變化？ 只在有限的時間範圍內，把中斷視為可能與該事件有關。
3. 使用者是否剛操作播放控制？ 觀察可信任的指標事件、播放控制目標，以及空白鍵、K 鍵或媒體播放按鍵等訊號。
4. 是否已記錄為手動暫停？ 若是，就停止恢復流程，直到播放重新開始。

這是結合事件與時間的啟發式判斷，不是瀏覽器直接告訴我們「這是使用者想暫停」。自訂播放器可能有不同控制方式，所以仍需要持續改善相容性。

以下是說明用的簡化偽程式碼，不是可直接部署的完整實作：

if 保護未啟用 or 媒體已結束 or 媒體發生錯誤:
    保留原本行為
else if 最近有播放控制操作 or 已記錄為手動暫停:
    尊重暫停
else if 最近發生背景切換 and 媒體原本正在播放:
    保護暫停呼叫，或嘗試有限次恢復
else:
    保留原本行為

在頁面側，實作會以包裝方式處理媒體的 pause() 呼叫；符合保護條件時才攔截，其他情況則交回原本的方法。停用時也需要清除監聽與計時器，並在可安全還原時恢復原本的方法，避免干擾後續播放。

在 content script 側，若符合恢復條件，則安排有限次的播放重試。媒體已移除、使用者手動暫停或條件失效時，都應停止。play() 也可能被瀏覽器政策拒絕，不能把呼叫已送出當成影片已經播放。

五、同頁有多個影片，不能全部喚醒

真實網頁可能同時放著主影片、預覽影片和其他媒體。選錯目標，即使防暫停邏輯正確，使用者仍會得到不想要的結果。

目前實作會結合播放狀態、媒體元素條件與相容設定來挑選主要媒體，而不是無差別恢復頁面上的所有影片。這也是為什麼「網站可以開啟」與「播放器完整相容」是兩回事。

可以用以下情境檢查設計是否合理：

• 正常播放後切換分頁：觀察是否減少網站引起的暫停。
• 手動暫停後再切換分頁：應維持暫停。
• 在另一個螢幕操作：區分失去焦點與真正不可見。
• 同頁有多個媒體：不應把所有媒體一起喚醒。
• 影片結束、來源移除或停用網站保護：不應繼續嘗試恢復。

這份清單是實作與相容性驗證的重點，不代表所有網站、系統組合都已通過實測。

六、延伸功能，也各有自己的限制

自動播放

使用者啟用後，進入或重新整理已新增網站時，嘗試播放主影片。網站可能動態加入播放器，因此要處理媒體晚出現的情況；目前也利用 DOM 變動觀察與有限次掃描尋找合適目標。

即使找到影片，瀏覽器仍可能禁止有聲自動播放。遇到這種情況要處理失敗結果，並由使用者操作後再嘗試，不能承諾任何網站進去都會自動播放。目前僅支援部分網站。

分頁增強

支援無限捲動，在瀏覽時提前載入並連續顯示下一頁內容；相容網站也能合併連續 2–5 頁。

實作難點不只是下載下一頁 HTML，還包含辨識內容容器、下一頁連結、頁碼，以及新內容插入後的相對網址與媒體載入。網站結構不同，必須有相容判斷；目前並非所有網站皆支援。

自動清除瀏覽紀錄

這是付費功能，預設關閉，需要使用者主動授權選用的 history 權限。實作上依已新增的網域比對瀏覽紀錄，再處理符合條件的網址與後續新紀錄。

啟用後，會永久清除所有已新增網站及其子網域的既有瀏覽紀錄，並持續清除新紀錄；刪除後無法復原。 所以設定介面必須把影響範圍說清楚。這也不等於清除網站伺服器紀錄、Cookie 或下載檔案。

七、適用範圍與後續方向

NoPause 處理的是電腦 Chrome 中，網站觸發的自動暫停問題，適合一邊聽影片、一邊查資料、做筆記、使用子母畫面或副螢幕的情境。它不是手機 YouTube 背景播放方案，也無法解決網路斷線、影片未載入或作業系統終止瀏覽器。

後續相容性工作會持續關注不同播放器的手動操作辨識、動態媒體元素，以及分頁增強中的網站結構差異。減少中斷與尊重使用者操作，都需要放進同一套設計裡。

如果你也做過瀏覽器擴充功能，歡迎交流：自訂播放器的「使用者暫停意圖」，你會如何辨識？

延伸參考

• Chrome 官方：Content scripts 與隔離執行環境
• MDN：Page Visibility API
• TMETE：我們的工具與開發分享