深色背景上的Chrome 106标志，左边是一个拿着笔记本的开发者的剪贴画。
这次我们将从弃用三个功能开始。在requestFileSystem()方法中，持久性配额类型将被弃用，因为它给代码增加了不必要的复杂性，由于其使用率低，这一点尤其不可取。HTTP/2推送流将遭受同样的命运，因为Chrome将不再接收、存储在内存中，或使用这种配置发送的流。同样，Chrome 106也将放弃对cookie域名属性中非ASCII字符的支持，这与RFC 6265bis规范中的最新标准化一致。
在新功能方面，一个主要的改进是支持SerialPort中的Bring Your Own Buffer（BYOB），以下是Google对它的描述：
开发人员可以通过调用getReader({ mode: 'byob' })来检测对BYOB读取器的支持，因为当新参数被传递时，旧的实现会抛出一个TypeError。BYOB（或者，"自带缓冲区"）阅读器允许开发者指定读取数据的缓冲区，而不是由流为每个块分配一个新的缓冲区。除了可能减少内存压力外，这还允许开发者控制收到多少数据，因为流不能返回超过所提供的缓冲区的空间。从一个端口读取特定数量的数据的能力使这个API对于习惯于针对Windows和POSIX串行设备API编程的开发者来说更加熟悉，这些API也是按照这个"自带缓冲区"的原则操作的。
自带缓冲区的阅读器允许开发者指定读取数据的缓冲区，而不是由流为每个块分配一个缓冲区。除了可能减少内存压力外，这还允许脚本控制在一个分块中收到多少数据，因为流不能返回超过所提供的缓冲区的空间。从一个端口读取特定数量的数据的能力一直是开发人员经常要求的功能，他们习惯于针对Windows和POSIX的串行设备API进行编程，这些API也是按照这种"自带缓冲区"的原则进行操作。相比之下，目前的API要求开发者对额外的不需要的数据进行防御性编码，而不是只读取他们准备处理的数据。
除此以外，无前缀的连字符属性CSS属性特性现在已经稳定，并将与Chrome 106一起发布。而"-webkit-hyphenate-character"属性将在以后一个未确定的日期被弃用。
Chrome 106浏览器的另一个关键改进是，它支持V3版本的Intl.NumberFormat API。
在这个版本的Chrome中也有一些实验性的功能。有两项开发者试验被隐藏在测试标记后，第一个是将文件系统访问API中的异步方法更新为同步方法。这将提高性能，并为API带来一致性。第二，Google将继续进行其减少用户代理的第五阶段计划。这个想法是为了改善隐私，同时也减少在解析复杂的用户代理字符串时出现错误的机会。
同样地，有两种能力也进入了Origin试验阶段，匿名iframes提供了一种通过短暂的上下文在外部iframes中加载文件的方法。由于它是跨源嵌入者政策（Cross-Origin-Embedder-Policy，COEP）的概括，从而取消了第三方iframes支持COEP的要求，这是嵌入到COEP页面的前提条件。这项试验将持续到Chrome 108。
一个弹出式API现在也通过Origin试验提供，它允许开发者在网络应用的顶部显示互动的瞬时UI元素。这与"对话框"元素类似，但有一些新的功能，如包括光照消失行为、弹出式互动管理、动画、事件支持等。
Chrome 106将在今天晚些时候开始推出。如果Chrome浏览器在一天中没有自动更新到106版本，请前往"帮助">"关于Google浏览器"，在更新可用时触发更新。接下来是Chrome 107，它将于9月29日进入测试频道，并将于10月25日发布稳定版。
最新文章