了不起的Chrome瀏覽器(13):Chrome 100支援多屏應用了!

寒雁發表於2022-04-02

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

TL;TR

Deprecate the document.domain setter是一個影響很大的breaking change,請大家務必注意排查風險。計劃於今年9月份釋出的Chrome 106將不再支援通過修改document.domain來繞開同源策略(same origin policy)的限制,Chrome 100開始在控制檯的Issues中列印warning資訊。

Multi-Screen Window Placement API是個很有意思的特性,Web應用也支援多屏了!可以用於文件演示等場景。可惜Firefox和Safari目前還不感興趣,只有Chrome一家支援。

Array Grouping proposal是個很簡單但是實用的特性,要不我們直接把Lodash的常用工具函式全部加入ECMAScript得了?

Reduce User Agent string information要結束試用,開始正式釋出了,此事對各種監控指令碼的影響還是挺大的,需要注意排查一下風險。

詳細解讀

Multi-Screen Window Placement API

Chrome 100正式釋出了Multi-Screen Window Placement API,可以用來查詢裝置所連線的多個螢幕的資訊,並且將頁面內容在指定螢幕中開啟,其核心API如下:

  • 新增window.getScreenDetails()方法,用於獲取顯示器螢幕的資訊(包括外接顯示器);相比之下,window.screen只能獲取當前瀏覽器頁面所在的顯示器螢幕資訊;
  • 支援使用window.open()、window.moveTo()以及requestFullscreen()將頁面內容在指定的螢幕開啟;

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

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

那麼,對於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等工具函式還是非常常用的:

image.png

如果哪天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欄位如下表:

請求Header取值示例
Sec-CH-UA"Chromium";v="84", "Google Chrome";v="84"
Sec-CH-UA-Mobile?1
Sec-CH-UA-Full-Version"84.0.4143.2"
Sec-CH-UA-Platform"Android"
Sec-CH-UA-Platform-Version"10"
Sec-CH-UA-Arch"arm"
Sec-CH-UA-Model"Pixel 3"
Sec-CH-UA-Bitness"64"

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

Web端的監控服務,例如ARMSFundebugSentry等,若需要獲取更加準確的客戶端資訊,則需要使用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.

截圖2022-03-26 17.25.33.png

好奇的小朋友可能就要問了,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.comhttps://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的市場佔有率,其絕對數量也是相當大,影響的使用者和開發者並不少:
截圖2022-03-27 下午5.16.30.png

總結

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、Phontoshop、Figama這樣重量級的應用出現在Web中,效能瓶頸會被逐漸突破,未來類似於視訊編輯、遊戲、VR/VA等應用會越來越多。

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

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

歡迎關注寒雁Talk公眾號,關注《了不起的Chrome瀏覽器》系列部落格,與我一起見證大前端的星辰大海!

參考資料

相關文章