Chrome 100 支持多屏應用了!

2022 年 3 月 29 日正式發佈的 Chrome 100,將帶來了哪些新特性呢?

文章來自:阿里巴巴前端標準化組

TL;TR

詳細解讀

一、Multi-Screen Window Placement API

Chrome 100 正式發佈了 Multi-Screen Window Placement API,可以用來查詢設備所連接的多個屏幕的信息,並且將頁面內容在指定屏幕中打開,其核心 API 如下:

簡單地說,Chrome 支持多屏應用了。

一圖勝千言,當我使用 Keynote 播放 PPT 時,它會在外接顯示器上展示 PPT 內容,而在 MacBook 顯示器上顯示下一頁內容以及當前時間,這樣的話,演講者可以把握演講的時間節奏並且提前準備一下下一頁要講的內容:

那麼,對於 Google Docs、語雀、石墨文檔等文檔應用,不妨可以使用 Multi-Screen Window Placement API 實現類似於 Keynote 的效果,用於演示場景。

其實,在金融、設計工具、遊戲等應用中,都可以用到 Multi-Screen Window Placement 接口,將不同的內容展示到不同的屏幕,提高用戶體驗和工作效率。

Twitter、Discourse、Google Slides、itrix 等團隊表達了對 Multi-Screen Window Placement API 的興趣,不過目前並沒有看到實際案例,而 Chrome 團隊所提供的 Demo 也過於簡單。

Multi-Screen Window Placement 提案還是挺有意思的,不過目前並沒有成爲正式標準,也沒有得到 Firefox 和 Safari 的支持,這就很尷尬了。。。

二、Array Grouping proposal

Chrome 100 開啓了 ECMAScript 提案 Array Grouping proposal 的開發者試用(devloper trial),該提案目前處於 Stage 3,爲數組新增了 groupBy 和 groupByToMap 方法:

const array = [1, 2, 3, 4, 5];

// 返回值:{ odd: [1, 3, 5], even: [2, 4] }
array.groupBy((num) ={
  return num % 2 === 0 ? "even" : "odd";
});

const odd = { odd: true };
const even = { even: true };

// 返回值:  Map { {odd: true}[1, 3, 5]{even: true}[2, 4] }
array.groupByToMap((num, index, array) ={
  return num % 2 === 0 ? even : odd;
});

根據 Web Almanac 2021 報告,Lodash 的使用率僅次於 jQuery 和 Modernizr,高於 React,由此可見類似於 goupBy 等工具函數還是非常常用的:

如果哪天 Lodash 的常用函數都變成了 ECMAScript 的提案,大家也不必意外。。。

三、Reduce User Agent string information

Chrome 95 開始試用 Reduce User Agent string information 特性,試用期將於 Chrome 100 結束,具體的結束日期爲 2022 年 4 月 19 日。Chrome 101 開始,將逐步正式發佈 Reduce User Agent string information 特性。

Reduce User Agent string information 旨在簡化 User-Agent 字符串,減少其信息量,緩解利用 User-Agent 字符串作爲用戶指紋,更好地保護用戶隱私。同時,引導開發者使用更加保護用戶隱私的 User-Agent Client Hints 來獲取瀏覽器信息,降低大家對 User-Agent 字符串的依賴。

Chrome 計劃到 Chrome 113 徹底完成 User Agent 字符串的簡化,不過從最終的結果來看,其實 User-Agent 的變化其實非常小。

以 Chrome Windows 用戶爲例,舊的 User-Agent 字符串是這樣的:

Mozilla/5.0 (Windows NT 6.3; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.1234.56 Safari/537.36

簡化之後最終的 User-Agent 字符串是這樣的:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/93.0.0.0 Safari/537.36

Windows NT 6.3 變成了 Windows NT 10.0,Chrome/93.0.1234.56 變成了 Chrome/93.0.0.0,僅此而已。Windows 的版本號被固定在了 10.0,即使用戶更新了操作系統,也不再變化了;Chrome 的版本號僅保留大版本號,省略了小版本號。換句話說,我們依然可以通過 User-Agent 字符串獲取瀏覽器的名稱及其大版本號、操作系統的名稱、區分桌面端和移動端。但是,我們無法通過 User-Agent 字符串獲取瀏覽器的小版本號以及操作系統的版本了。另外,對於安卓端,手機的品牌及型號也不再提供。

User-Agent 字符串所能提供的瀏覽器信息更加模糊了,這樣有利於保護用戶隱私。

如果開發者需要獲取更加精確的瀏覽器信息,則需要使用 User-Agent Client Hints,該特性在 Chrome 89 已上線。User-Agent Client Hints 對應的 HTTP 請求 Header 字段如下表:

瀏覽器默認僅發送 Sec-CH-UA、Sec-CH-UA-Mobile、Sec-CH-UA-Platform,與 User-Agent 所提供的信息量一致,如果服務端需要獲取其他 User-Agent Client Hints 字段的話,則需要明確指定所需要的字段。這樣做的好處在於,瀏覽器默認提供的用戶信息更少了,同時瀏覽器及 Web 應用理論上能夠記錄、審計服務端所請求的信息量,能夠更加主動地保護用戶隱私。

Web 端的監控服務,例如 ARMS、Fundebug、Sentry 等,若需要獲取更加準確的客戶端信息,則需要使用 User-Agent Client Hints 了。當然,建議使用 User-Agent Client Hints 需要獲得用戶的授權,插件以及應用端不應該幫用戶做決定,否則這個特性對用戶隱私的保護就沒有實際意義了。

四、Deprecate the document.domain setter

計劃於今年 9 月份發佈的 Chrome 106 將不再支持通過修改**document.domain**來繞開同源策略(same origin policy)的限制,Chrome 100 開始在控制檯的 Issues 中打印 warning 信息。

例如,訪問 https://www.google.com 時,其原本的 document.domain 取值爲 www.google.com,我將其修改爲 google.com 之後,Issues 中將會出現 Deprecated Feature Used 信息:

Relaxing the same-origin policy by setting "document.domain" is deprecated, and will be disabled by default in M106, around September 2022. To continue using this feature, please opt-out of origin-keyed agent clusters by sending an Origin-Agent-Cluster: ?0 header along with the HTTP response for the document and frames. See https://developer.chrome.com/blog/immutable-document-domain/ for more details.

好奇的小朋友可能就要問了,document.domain看着就不應該支持修改,正經人誰改這個啊!

是這樣的,當我們在 https://parent.example.com 中嵌入來自 https://video.example.com 的 iframe 頁面時,兩者的主域名都是 example.com,但是子域名不同,因此不是同源(same-origin),如果將兩者的 document.domain 都設爲 example.com 的話,它們就變成同源了。因此,修改 document.domain 是爲了繞開同源策略的限制,這樣主頁面和 iframe 頁面就可以互相讀取和修改 DOM 了,比如給內嵌視頻增加 autoplay 屬性。

同源策略(same origin policy)是 Web 應用最基本的安全基礎之一,這麼 1 行代碼就輕易地繞開了?

這顯然是一種 hack 的做法,違背了同源策略的初衷,存在安全風險,比如對於類似 GitHub Pages 這種網頁託管服務來說,各個用戶的子域名不同,主域名相同,這時理論上通過修改 document.domain 是可以繞開同源策略的限制的。

所以,Chrome 決定堵住這個安全漏洞,修改 document.domain 將不能繞開同源策略的限制,Firefox 也表示了支持。

如果你依然需要進行 https://parent.example.com 與 https://video.example.com 之間的通信,則可以使用 postMessage() 或者 Channel Messaging API。

如果你依然需要通過修改 document.domain 繞開同源策略的限制,或者來不及進行改造的話,可以返回 HTML 文件時,增加以下 Header:

Origin-Agent-Cluster: ?0

Chrome 致力於讓 Web 變得更加安全,爲了這個目標,不停地折騰全世界的 Web 開發者,這種做法讓人不得不服,誰叫它說了算,大家還是趕緊檢查一下你的代碼裏面是否修改 document.domain 了吧!

根據 Chrome Platform Status 的數據,大概有 0.5% 的頁面加載通過修改 document.domain 來繞開同源策略的限制,這個比例很低,但是考慮到 Chrome 的市場佔有率,其絕對數量也是相當大,影響的用戶和開發者並不少:

總結

2008 年,祕密開發 2 年的 Chrome 正式發佈,14 年之後,Chrome 的版本號達到了 100。

Chrome 的 UI 設計基本上沒什麼變化,不過它的內核已經煥然一新了,Web 技術獲益於 Chrome 的推動得到了長足的進步

相信 Chrome 100 只是起點,隨着 WebAssembly、WebGPU、HTTP/3 等各種 Web 新技術得到應用,未來的 Web 會更加精彩!

這裏,不妨模仿一下 Atwood's Law:

Any application that can be written in Web, will eventually be written in Web.

我們已經看到 AutoCAD、Google Earth、Photoshop、Figma 這樣重量級的應用出現在 Web 中,性能瓶頸會被逐漸突破,未來類似於視頻編輯、遊戲、VR/VA 等應用會越來越多。

我有差不多 2 個月沒有更新 Chrome 博客,其實,Chrome 98 和 Chrome 99 的博客寫得差不多了,但是由於春節假期以及疫情的原因,沒有及時發佈。按時更新 Chrome 博客是一件難的事情,不過我還沒打算放棄,繼續堅持!

才疏學淺,我所寫的內容難免有錯誤之處,歡迎批評指正,感興趣的同學可以微信交流:KiwenLau

參考資料

本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源https://mp.weixin.qq.com/s/DzpSn8VTfGhF-rN89E158A