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水平。。。）：

那么，对于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字段如下表：

请求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端的监控服务，例如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、Phontoshop、Figama这样重量级的应用出现在Web中，性能瓶颈会被逐渐突破，未来类似于视频编辑、游戏、VR/VA等应用会越来越多。

我有差不多2个月没有更新Chrome博客，其实，Chrome 98和Chrome 99的博客写得差不多了，但是由于春节假期以及疫情的原因，没有及时发布。按时更新Chrome博客是一件难的事情，不过我还没打算放弃，继续坚持！

才疏学浅，我所写的内容难免有错误之处，欢迎批评指正，感兴趣的同学可以微信交流：KiwenLau。

欢迎关注寒雁Talk公众号，关注《了不起的Chrome浏览器》系列博客，与我一起见证大前端的星辰大海！

了不起的Chrome浏览器（13）：Chrome 100支持多屏应用了！