在几乎每个版本的 Chrome 中，我们都看到了针对产品及其性能以及网络平台功能的大量更新和改进。本文介绍了自 6 月 9 日起 Chrome 52（Beta 版）中的变化。此列表随时可能发生变化。
基于 DHE 的加密算法将逐步淘汰
要点：Chrome 53 桌面版移除了基于 DHE 的密码，因为它们不够长期使用。服务器应采用 ECDHE（如果可用）或普通 RSA 加密（如果不可用）。
意图移除 | Chromestatus Tracker | Chromium 错误
去年，我们在 Chrome 中设置了最小 TLS Diffie-Hellman 组大小，从 512 位到 1024 位；但是从长期来看，1024 位是不够的。指标报告称，Chrome 检测到大约 95% 的 DHE 连接使用了 1024 位 DHE。再加上 TLS 中 DHE 的协商方式，使得迁移到 1024 位就变得困难了。
虽然有一个规范草稿可以解决此问题，但它仍处于草稿状态，需要对客户端和服务器进行更改。与此同时，ECDHE 已得到广泛实施和部署。服务器应升级到 ECDHE（如果有）。否则，请确保已启用普通 RSA 加密套件。
自 Chrome 51 起，基于 DHE 的加密方式已被弃用。我们将从 Chrome 53 的桌面设备中移除支持。
FileError 弃用警告
要点：Chrome 54 预计会移除已废弃的 FileError 接口。将对 err.code 的引用替换为 err.name 和 err.message。
意图移除 | Chromestatus Tracker | Chromium 错误
当前版本的 File API 标准不包含 FileError 接口，而且对此类接口的支持已于 2013 年的某个时候弃用。在 Chrome 53 中，以下弃用警告将输出到开发者工具控制台：
“FileError”已被弃用，并将在 54 中移除。请使用错误的“name”或“message”属性，而不是“code”。
这在不同情况下会产生不同的效果。
FileReader.error和FileWriter.error将是DOMException对象，而不是FileError对象。- 对于异步
FileSystem调用，系统将向ErrorCallback传递FileError.ErrorCode，而不是FileError。 - 对于同步
FileSystem调用，系统会抛出FileError.ErrorCode，而不是FileError。
此更改只会影响那些依赖于直接将错误实例的代码 (e.code) 与 FileError 枚举值（FileError.NOT_FOUND_ERR 等）进行比较的代码。针对硬编码常量（例如 e.code === 1）进行测试的代码可能会由于向用户报告错误错误而失败。
幸运的是，FileError、DOMError 和 DOMException 错误类型都使用 name 和 message 属性，这两个属性为错误情况提供了一致的名称（即 e.name === "NotFoundError"）。代码应使用这些属性，它们将跨浏览器运行，并且在 FileError 接口本身被移除后将继续工作。
我们预计会在 Chrome 54 中卸载 FileError。
移除 <input type=search> 的结果属性
要点：我们即将移除 results 属性，因为它不属于任何标准，而且在各个浏览器中的实现方式也不一致。
意图移除 | Chromestatus Tracker | Chromium 错误
results 值仅在 webkit 中实现，在采用该属性时行为方式不一致。例如，Chrome 会向输入框添加一个放大镜图标，而在 Safari 桌面版上，它会通过点击放大镜图标来控制在弹出式窗口中显示的次数。由于此 API 不属于任何标准，因此即将被弃用。
如果您仍需在输入字段中添加搜索图标，则必须为元素添加一些自定义样式。为此，您可以添加背景图片，并在输入字段上指定左内边距。
input[type=search] {
background: url(some-great-icon.png) no-repeat scroll 15px 15px;
padding-left:30px;
}
```
This attribute has been deprecated since Chrome 51.