在絕大多數的 Chrome 版本中，我們都發現大量的更新和改善項目，包含產品、效能和網路平台的功能。本文說明 Chrome 60 將於 6 月 8 日推出的 Beta 版淘汰和移除功能。這份清單隨時可能有所變動。
安全性
crypto.subtle 現在需要安全的來源
自 Chrome 37 版起，一直支援不安全的 Web Crypto API。根據 Chrome 長期政策，將安全來源優先於強大功能，crypto.subtle 並不會顯示在安全來源上。
移除從內容啟動的頂端頁框瀏覽資料網址
由於非技術性瀏覽器使用者不熟悉，因此我們越來越常看到用於假冒和網路釣魚攻擊的 data: 配置。為了避免這種情況，我們已禁止網頁在頂層頁框載入 data: 網址。這適用於 <a> 標記、window.open、window.location 和類似機制。data: 配置仍適用於頁面載入的資源。
這項功能已在 Chrome 58 版中淘汰，現已移除。
意圖移除 | Chrome 狀態追蹤工具 | Chromium 錯誤
暫時停用部分 blob 的 navigator.sendBeacon()
navigator.sendBeacon() 函式自 Chrome 39 以上版本推出。如同原先實作，函式的 data 引數可包含類型非 CORS 安全清單的任何任意 blob。我們認為這是潛在的安全威脅，但還沒有人試圖利用。由於我們無法立即解決這個問題，因此暫時無法對類型為「不」屬於 CORS 安全清單的 blob 叫用 sendBeacon()。
雖然此變更已針對 Chrome 60 實作，但現已合併至 Chrome 59。
CSS
讓影子穿過分子組合成子組合模式
CSS 範圍模組層級 1 中的影子穿插子組合 (>>>) 旨在比對特定祖系元素的子項，即使這些子元素出現在陰影樹狀結構中也一樣。這有幾項限制。
首先，根據這些規格，這只能用在 JavaScript 呼叫 (例如 querySelector()) 中，無法在樣式表中使用。更重要的是，瀏覽器供應商無法讓其運作方式超過 Shadow DOM 的一個層級。
因此，子組合器已從相關規格中移除，包括 Shadow DOM v1。我們之所以選擇從 Chromium 移除這個選取器，而不是透過從 Chromium 移除這個選取器，改為將影射子組合子設為子系組合中的別名。原始行為已在 Chrome 45 版中淘汰。 Chrome 61 實作新行為。
意圖移除 | Chrome 狀態追蹤工具 | Chromium 錯誤
JavaScript
淘汰並移除 RTCPeerConnection.getStreamById()
將近兩年前，getStreamById() 已從 WebRTC 規格移除。大多數其他瀏覽器已從實作項目中移除這個項目。雖然很少用到這個函式，但它認為，除了支援 getStreamById() 的 Safari「以外」，我們也認為以 Edge 和 WebKit 為基礎的瀏覽器會出現些微的互通性風險。需要其他實作方式的開發人員可在下方「要移除的意圖」中找到程式碼範例。
Chrome 62 不支援這項功能。
意圖移除 | Chrome 狀態追蹤工具 | Chromium 錯誤
淘汰 SVGPathElement.getPathSegAtLength
超過兩年前，我們已從 SVG 規格中移除 getPathSegAtLength()。由於 httpArchive 中只有少數會使用這個方法的命中資料，因此 Chrome 60 會淘汰這個方法。我們預計於 Chrome 62 推出移除內容，並於 10 月初或中旬推出。
Intent to Deprecate | Chromestatus Tracker | Chromium 錯誤
將 getContextAttributes() 移至標記後方
自 2013 年起，CanvasRenderingContext2D 均支援 getContextAttributes() 函式。但該功能並非任何標準的一部分，從那時起亦未加入其中。這應在 --enable-experimental-canvas-features 指令列旗標後方實作，但實際上並非如此。Chrome 60 的這項監督措施已經修正。沒有任何資料顯示任何人正在使用這個方法，因此我們認為這項變更是安全的。
移除 Headers.prototype.getAll()
Headers.prototype.getAll() 函式即將根據最新版本的擷取規格移除。
意圖移除 | Chrome 狀態追蹤工具 | Chromium 錯誤
移除 indexDB.webkitGetDatabaseNames()
當已建立索引的資料庫在 Chrome 中相對較新，且在前置字串方面造成重複性的影響，我們新增了這項功能。API 會以非同步方式傳回來源中的現有資料庫名稱清單，讓名稱顯得合理。
可惜的是，這項設計沒有問題，因為結果傳回後可能會立即過時，因此實際上只能用於記錄，而非嚴重的應用程式邏輯。GitHub 問題會追蹤先前討論替代方案的相關內容/連結，而這類問題必須採用其他方法。雖然開發人員受到開發人員的青睞，但由於缺少跨瀏覽器可以推動這個問題，因此程式庫作者已著手解決這個問題。
需要這項功能的開發人員需要自行開發解決方案。舉例來說，Dexie.js 等程式庫會使用全域資料表，該資料表本身是另一個資料庫來追蹤資料庫名稱。
這項功能已在 Chrome 58 版中淘汰，現已移除。
意圖移除 | Chrome 狀態追蹤工具 | Chromium 錯誤
移除 WEBKIT_KEYFRAMES_RULE 和 WEBKIT_KEYFRAME_RULE
從 CSS 規則中移除非標準 WEBKIT_KEYFRAMES_RULE 和 WEBKIT_KEYFRAME_RULE 常數。開發人員應改用 KEYFRAMES_RULE 和 KEYFRAME_RULE。
意圖移除 | Chrome 狀態追蹤工具 | Chromium 錯誤
使用者介面
要求使用者必須透過手勢才能卸載對話方塊
從 Chrome 60 以上版本開始，只有在影格嘗試顯示它收到使用者手勢或使用者互動 (或任一嵌入頁框收到這類手勢) 時，才會顯示 beforeunload 對話方塊。明確來說，這並非針對 beforeunload 事件的分派變更。改變是否顯示該對話方塊。
beforeunload 對話方塊是應用程式互動對話方塊。因此，它本來就會由使用者代管，也就是藉由詢問使用者的決定來回應使用者的瀏覽動作。這項功能已妥善運用。例如，當使用者透過導覽操作會遺失資料時，這項功能經常用於警告使用者。
儘管網頁提供 beforeunload 對話方塊文字的功能已經移除，但 beforeunload 對話方塊仍屬於濫用媒介。特別是，beforeunload 對話方塊是詐騙網站的關鍵，其中自動播放的音訊和威脅文字可以協助 Chromium 提供有關「確定要離開這個網頁」訊息的背景資訊。
我們想要執行緒，並僅允許妥善使用 beforeunload 對話方塊。對話方塊的良好用途，就是使用者可能遺失狀態的情況。如果使用者從未與網頁互動，就不能有任何可能遺失的狀態，因此在此情況下，我們隱藏對話方塊並不會造成使用者資料遺失。