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