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 字段如下表：

浏览器默认仅发送 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 浏览器（7）：Chrome 95 终于反对 WebAssembly 异样解决了！
• 了不起的 Chrome 浏览器（10）：2021 年，Chrome 哪些变动最值得关注？
• Chrome 100 Beta: Reduced User-Agent Strings, Multi-Screen Window Placement, and More
• Managing several displays with the Multi-Screen Window Placement API
• User-Agent Reduction Origin Trial and Dates
• Chrome will disable modifying document.domain to relax the same-origin policy