WebKit 贡献者会议 2023

WebKit 贡献者会议 2023 年 10 月 24-25 日

日程

周二会议

演讲	演讲者
Sony WebKit 2024 优先事项	Don Olmstead
Igalia 和 WebKit：状态更新和计划	Mario Sánchez Prada
Apple 的 WebKit 计划：2024 版	Maciej Stachowiak
管理 WebKit 中的安全变更	Jonathan Bedard
云游戏的现状	Byungseon(Sun) Shin
贡献 Web Inspector	Devin Rousso

周三会议

演讲	演讲者
WPE 平台 API	cgarcia
Gstreamer WebRTC 状态	Philn
WebKitGTK 和 WPE 端口 SDK	Patrick Griffis
LBSE 状态	Nikolas Zimmermann 和 Rob Buis

闪电演讲	演讲者
垂直表单控件	Aditya Keerthi
瀑布流布局	Brandon Stewart
Speedometer 3	Ryosuke Niwa
所有字体特性（提案）	Frances Cornwall
Playwright 与现代端到端测试现状	Pavel Feldman
标准立场页面与贡献	Anne van Kesteren
在 JSC 中实现 WebAssembly GC 提案	Asumu Takikawa
在 Windows 端口上启用 WebAssembly 和 FTL JIT	Ian Grunert
向客户交付 Web API	Tim Nguyen 和 Elika J. Etemad
Quirks: 网页的金继	Karl Dubost
提案：新的 WebKit 标志	Jon Davis

演讲

周二

Sony WebKit 2024 优先事项

备注

• Wincairo：构建和构建维护。MSVC 2023 问题。
• Windows Playwright 很有趣 - webDriver-sh，看起来非常有前景。
• Http3：Curl 后端是实验性的，但正在努力解决 Bug。
• WASM 支持：我们的兴趣在于无 JIT。目前处于实验和研究阶段。
• JS：Ross Krisling 继续致力于 TC39 标准。
• LibWPE
  • 与 Igalia 合作进行硬件垂直同步。视频和游戏手柄（与 VR 结合的振动和触觉的新版本）。
  • 希望将其推向发布状态
• 图形
  • WC 合成器移植到 PlayStation
  • GPU 进程对于安全而言尤为重要。
  • WebGPU - 目前使用 Google 的 Dawn 后端
  • 能够在 PS 端口上实现基本的初步渲染。
  • 希望将其移入更广泛的 WebKit 项目

问题

• PS4 和 PS5 使用 WebKit 的方式不同吗？
  • 大多数情况下不
  • 有任何 web-transport 示例吗？一些内部团队由于视频而对此感兴趣。
• Windows 和 PlayStation 端口之间的连接是什么？
  • Web Inspector 和调试工具
  • 后端部分 - CURL、cairo、合成器
• Wincairo -> WebKit Windows 浏览器涉及多少？
  • 很想，但资源和公司目标受限
  • Minibrowser 是一个很好的起点，但还有很多可以构建。
• GPUProcess 和 WC 合成器——成功了多少？
  • Windows 正在运行。(富士)

Igalia 和 WebKit：状态更新和计划

幻灯片

备注

• Mario 是 Igalia WebKit 团队的协调员
• Igalia 是一家开源咨询公司，完全远程，扁平化结构，为 WebKit、Chromium Gecko、Servo 等引擎做出贡献
• Igalia 为 W3C 和其他规范机构做出贡献
• 在 WebKit 内部，Igalia 主要作为 WebKitGTK 和 WPE 端口的维护者，以及 Web 标准和 Javascript 特性的实现者
• Igalia 在 WebKit 的其他部分也投入时间，例如 Bug 修复、重构、性能、32 位支持、QA 等。
• 运行 WebKit 的嵌入式设备列表：机顶盒、智能家居、医疗设备、导航、数字标牌、QA 等。
• 我们的用户是谁？
  • 我们有多种类型的用户，从他们使用引擎的角度来看
    • 端口用户（应用开发者）、平台提供商（如 fedora、yocto）
    • Web 开发者在不同引擎中测试事物
    • 访问网络的最终用户
• 战略目标
  • 我们的目标是兼容性和互操作性，这意味着平台良好且同质化
  • 性能在嵌入式设备中非常重要，以及硬件资源的使用效率
  • QA 和安全性是确保产品持续运行的基础
  • 开发工具和文档是良好发展故事的关键部分
  • 改善与 WebKit 社区内部其他端口的协作是一个目标
• 接下来我们将讨论最近的工作，之后是我们的计划
• WebKit 贡献者 2023
  • WebKit 项目中提交数量的图表
  • 主要是 Apple，Igalia 排名第二，索尼和 RedHat 随后
  • Igalia 提交了 50% 的非 Igalia 提交
  • 前几年我们有更高的百分比，因为现在我们从其他贡献者那里获得了更多的提交
  • 这对于项目的健康状况来说是好的
• Web 平台贡献
  • CSS 属性：content-visibility
  • HTML Fetch Priority
  • Popover API
  • Secure curves
  • 我们今年实现了这些标准
• 图形
  • 今年我们在这里做了大量工作
  • 在特定端口方面和核心方面
  • 完成 ANGLE 集成和 WebGL2 支持
  • 进程间共享缓冲区是我们未来发展的重要组成部分，我们正在努力转向这种架构
  • 我们清理了一些其他东西，例如：移除 Wayland 服务器，使用 displayLink 架构进行同步
  • 我们一直在努力替换 cairo 作为 2D 渲染引擎
    • 今天我们没有什么可展示的，但这是内部的一项巨大努力
  • 我们有实验性的 GPUProcess 支持
  • 我们在 LBSE 工作中将 SVG 层实现为一等公民
• 多媒体
  • 我们最大的用户是 STB，这意味着多媒体很重要
  • 我们完成了 DMAbuf sink 集成
  • WebCodecs, 使用 gstreamer 的 WebRTC, 改进的功耗等等。
• JSC
  • 我们最大的努力是支持 32 位
  • 我们为 ARMv7 添加了多项功能
  • 我们致力于 WASM GC，这是 Asumu 明天演讲的主题
• 新的 WPE API
  • 我们当前的 API 存在一些问题，它在过去因某种原因而创建，但我们希望改变这一点
  • Wayland 中心化，API 文档缺乏，复杂性
  • 我们计划创建一个更简单的新 API
  • 我们已经开始着手这项工作
  • 我们正在开始推送补丁
  • 明天 Carlos 将谈论这个
• Android 上的 WebKit
  • 去年我们展示了它
  • 这个想法是使用 WebKit 在 Android 上使用不同的引擎
  • 今年我们没有那么多时间来做这件事
  • 我们正在使用 WPE API
  • 我们支持多种架构、原生集成等。
• 质量保证
  • 这不是我们端口中最强项
  • 今年我们看到了许多问题
  • 我们为团队增加了更多人手，并花费大量时间修复 API 和布局失败
  • 数字很有趣，我们增加了运行的测试数量，并减少了跳过的测试数量
  • 我们可以看到当前情况的图表
  • 情况不佳，但我们正在改进，不过我们仍然对现状不满意
  • 我们减少了不稳定性
  • 我们正在将工作重心转移到 GTK
  • WPE 的情况更好，这是我们努力的结果
• 出于安全考虑，我们每年都会发布多个版本
• 我们会在网站上发布它们
• 工具和文档
• 我们希望迁移到新的 GitHub 文档基础设施
• QA 部门的人员负责这项工作
• 在工具方面，我们付出了巨大的努力
• Patrick 明天会谈论这个
• WebKit 不是一个容易的项目，我们希望为开发人员和测试人员提供一个解决方案
• 我们现有的解决方案要么适用于一方，要么适用于另一方，但不能同时适用于双方
• 所以我们创建了一个基于容器的解决方案
• OCI 兼容容器
• 你可以下载并使用它，甚至可以修改依赖项
• 例如，这对于从事 Gstreamer 工作的人很重要
• 下一步
• 在 Web 平台上
• 我们将致力于 Navigation API 和 hasUAVisualTransition
• 图形
  • 重构在明年很重要
  • 在架构中更广泛地使用 dmabuf
  • 尽快替换 2D 引擎和 GPUProcess
  • 新的 SVG 引擎应在明年完全上游化，且不应有任何性能退步
• 多媒体
  • gstreamer webrtc 后端和一般维护是我们计划进行的主要工作
• JSC
  • 主要是 ARMv7 改进
  • 启用 OMG 和 FTL
  • 实现 WASM GC
• 新的 WPE API
  • 完成一些初始版本，审查 API 文档并在我们认为准备就绪时弃用旧版本
  • 我们希望尽快开始提交补丁
  • 没有具体的发布日期
• Android 上的 WebKit
  • 我们希望在 Android 上提供 WPE 的第一个可用版本
• 我们列出了未来一年计划的下一步骤
• QA
  • 我们需要改进测试运行和修复的图表
  • 我们有新的 SDK，希望它能帮助改善现状
  • 准备 GTK4 机器人，因为它是下一个版本
  • 工具和文档
    • 发布 SDK 的第一个版本
    • 并改进文档

问题

• ARMv7 中的 WASM BBQJIT，寄存器支持的工作
• 他们谈论如何在 ARMv7 架构中分配寄存器的具体细节
• cairo 替换，这也是您尝试用于 Windows 的吗？
• 目前主要用于 Linux，但我们不排除在 Windows 上运行也很重要
• 回归图表来自哪里
• 它来自我们端口的 WebKit 测试猎人
• Android 版 WebKit，您希望有人能用它创建浏览器，还是您有特定的利基用例？
  • 理想情况下，它可以完全替代，但我们目前没有所有功能
• 我们提出了一个关于 Windows 寄存器分配的建议，他稍后可以更具体地讨论
• 您是打算将 Android 支持用作通用浏览器，还是作为 WebView 替代品？
• Mario 解释说它将成为 WebView 的替代品
• 对 CI 端，Windows 使用容器感到好奇
• 我们已经在机器人中使用 LXC 容器
• 这个想法是在机器人中使用 SDK 容器
• 无论是在 LXC 中运行还是直接运行

云游戏的现状

幻灯片

备注

• 议程
  • 什么是云游戏
  • 与普通视频游戏有何不同
  • W3C 工作组目前的标准化活动
• 什么是云游戏？图形渲染在云端。客户端不需要高性能机器。
• 客户不需要每年升级硬件主机
• 点击到像素延迟是主要的性能指标之一。
• 在云游戏中建议低于 150 毫秒
• 幻灯片：120fps 处理时间线。
• 演示（录制视频）（已编辑）
• W3C WebRTC 工作组的当前标准活动
  • 有损网络条件下的质量改进
  • 更快的视频恢复
  • 一致的延迟
• NVIDIA 尝试向工作组提案
• macOS/iOS 主题
  • WebRTC 发布周期，每年一次
  • 更高的 4K 分辨率支持（HEVC 隐藏在一个标志后面）
  • 用户输入：游戏手柄、键盘和鼠标

问题

• 幻灯片：与普通视频流有何不同
  • 超低延迟
  • 一致的延迟
  • 视频内容
  • QoS
  • ……等等
• WebTransport 或 WebCode 代替 WebRTC 如何？
  • 是的，内部正在考虑。

贡献 Web Inspector

幻灯片

备注

• Devin 在 Web Inspector 上工作了 8 年。
• 将进行总结。
• 可调试对象是您正在检查的主要内容
• 目标是被调试的对象（例如，Javascript、页面、服务工作者）
• 你可能有两个独立的列表，这可能很奇怪……有些是一对一的。
• 但其他则允许一对多关系。例如，网页可以调试很多东西
• 前端是我们的 UI。
• 后端是我们正在检查的页面。
• 协议用于“前端”和“后端”之间的通信
• 本次演讲将重点关注协议……协议是自动生成的。
• 还有“远程”概念，这对设备很重要……比如连接到 iOS 和模拟器
• 通过远程，我们获得了一些关于 IPC 的保证
• 前端只是纯粹的 Javascript 和 HTML、CSS 等。
• InspectorFrontendHost 只是一个特殊的 API（非标准）
• InspectorFrontendAPI 是事物与 Web Inspector 对话的方式
• 我们使用了一些框架来帮助我们（例如，codeMirror）。
• 我们广泛使用事件监听器
• 我们有一个“自定义布局引擎”™
• 我们将其用作“视图”，并使用 requestAnimationFrame 等来保持所有内容同步。
• 我们遵循简单的 MVC
• 控制器主要是“管理器”……前端通常是单例
• 它们处理协议通信
• 它们需要知道它们正在与哪个目标进行通信和处理
• 但除此之外，就只是模型和视图
• 模型只是数据封装器
• UI 分为多个相互作用的区域
• 在您交互时，每个区域都会获得元数据来控制 Web Inspector 的各个方面。
• Web Inspector 关心 RTL、深色模式等，因此在为项目做贡献时需要注意这一点
• 有各种附加到 WI.* 的 API... WI.Table, WI.NavigationBar 等作为组件。
• 这些组件有很多使用示例。这让新开发者更容易贡献
• 该协议几乎完全是自动生成的
• 基于 JSON 的基本 IPC 系统
• 有很多协议
• 还有其他域。
• 例如，CSS 域对应于 CSS 相关事物，运行时是“javascript”
• 新域只需用 JSON 指定
• 除了域之外，还有相应的类型
• 它提供了类型安全和保证
• 此外，它还提供了事件和预期的结构
• Devin 展示了一个域定义在 JSON 中的示例
• 同样地，对于类型……我们将其定义为“type”：“integer”
• 使得理解起来非常容易……枚举也一样
• 例如，“before”和“after”
• 然后变得更复杂
• 但也不至于太复杂
• 您还可以指定“命令”……例如，“getDocument”……这将从前端发送到后端，并且它发送命令的序列化版本。
• 作为一名开发人员，您只需实现前端调用和后端功能，而无需担心 IPC。这一切都由系统为您处理。（已编辑）
• 对于事件，只存在与之关联的参数。这使得事情变得简单。
• Web Inspector 需要考虑
  • Inspector Web 进程
  • Inspector UI 进程
  • 被检查的 UI 进程
  • 被检查的 Web 进程
• 以及它们如何相互通信/路由。我们为您处理这些。您无需接触这些代码，以使其更简单。
• 但重要的是，“检查器”和“被检查对象”可能是完全不同的设备。但作为开发人员，您无需担心这一点
• 新的 macOS 可以检查旧的 iOS，但旧的 iOS 不能检查新的 macOS……也就是说，你可以检查“过去”，但不能检查未来
• 我们有自动化系统来检查后端是否支持特定命令
• 这非常有帮助，所以你可以恢复
• 同样，这一切都是自动生成的。
• ……Devin 展示了如何用 JS 完成此操作……前端和后端之间的通信
• ……大量 JS 代码……
• 同样，对于事件……也不是那么难
• 大量使用 WTFJSON
• 后端……每个可调试对象都有一个顶层控制器对象
• 它负责创建一个代理来帮助处理一个域……它为该域提供了功能。
• 例如，所有都会有一个运行时代理，因为它们都使用“javascfript”进行通信，但它们通常是专门的
• 有一些专门的对象可以帮助您处理您可能想要调试的不同事物。
• 一般提示……代码库中有很多现有的内容。唯一令人困惑的部分是协议。
• 但一般来说，一切都相当简单
• 你甚至可以使用 Web Inspector 检查 Web Inspector
• 我们依靠 ESLint
• 保持代码干净和一致
• 几乎没有 UI 测试……你不必编写测试……但缺点是你需要手动测试
• 无需等待 EWS……更改 UI 很容易

Razvan，当您在后端创建代理时，如何维护蔓延？

• 通常会尝试思考它属于哪个类别？（例如，查看 MDN）……你可以说你可以创建一个新域。如果可能，尝试使用现有代理。或者如果它需要一个特殊情况才能与多个代理通信。你需要仔细考虑域和代理来处理不同的情况。所以是的，思考架构并尽可能多地重用
  • 我尝试修改代码 UI……你打算添加 UI 框架吗？
• 我们不是 UI 框架的狂热爱好者，因为它们可能会碍事。我们喜欢好好命名事物，并保持事物超级简单。视图系统就是我们的答案。我们有一个非常基本的系统，只有大约 20 行代码。
  • 我们定义规则。并且我们对自己强制执行这些规则
  • 我们处理的代码越少越好。如今，我们不再需要 jQuery 之类的东西了，因为浏览器现在好多了
  • 来自 Sony 的 Don。您可以使用 Web 平台上可用的任何东西。您希望看到更多什么样的 Web 平台？
• 我们看到很多 `var` 的用法，但如果它能正常工作，我们通常会保留它们。我们使用新事物作为试验台，但我们不会特意去使用。例如，未来我们会一直替换旧功能，并在新功能可用时使用新功能？
  • 您在 EWS 上使用 ESLint 还是计划使用？
• 我们通常将其作为指导，但有时由于各种原因我们不同意 ESLint。所以，更多的是一种指导原则。
  • 评论：Karl。我经常使用 Web Inspector 进行 Web 兼容性测试。当您修复 Web Inspector 时，它对修复整个 Web 平台的健康状况非常有帮助。
• 请多修复一些东西
• Devin：当然。我们希望帮助所有人——Web 开发者和 WebKit 工程师。
• 我们有时甚至会为 Web Inspector 开发者做一些非常具体的事情。我们也会为 WebKit 工程师添加一些特定的东西，但这些东西也能让 Web 开发者受益
• Frances。您有什么建议可以帮助 WebKit 工程师找到 Web Inspector 的 Bug 吗？
• 没有明确的方法可以找到它们，也没有具体的列表。我确信有很多。
  • Razvan：重述一下，Bugzilla 是提交 WebKit Bug 的正确地方吗？
• 是的，把事情放在 Web Inspector 组件下。
  • Elika，精彩的演讲！我们稍后在哪里可以找到这些信息？
• 好问题。我想写一篇关于这个的博客文章。我没有演讲稿。
  • 周三

WPE 平台 API

幻灯片

备注

我们正在开发新的 WPE API

• 当前状态
• 目前的架构将 WPE 作为用于渲染和输入处理的外部库
• 后端实现渲染和输入处理的接口
• 我们有支持 Wayland 的 fdo 后端
• 还有其他后端，例如用于机顶盒的 RDK
• 我们有 Cog，这是一个可以作为参考实现的浏览器
• 这种模型的问题
• 我们有多个问题
• 我们设计时使用 EGL 和 Wayland 进行渲染
• 但随着时间的推移，我们意识到在没有 EGL 和 Wayland 的情况下可以渲染得更好
• wpe 是一个外部库
• 由 WPEWebKit、后端和应用程序使用
• 这样 libwpe 就无法明确 UI 进程和 Web 进程需要哪些部分
• 它有自己的 IPC 机制
• 维护起来不容易，因为我们必须与 WPEWebKit 和 cog 的发布版本同步
• 缺乏文档
• 仅仅简单的实现就需要大量的理解
• cog 不仅仅是一个参考，它还包含大量补充的胶水代码
• 这就是它主要被使用的原因
• 新架构
• 我们想摆脱 Wayland 模型
• 并使用目标平台可以提供的缓冲区共享机制
• WebProcess 的渲染独立于目标平台
• 使用 gbm 或 surfaceledd 上下文，我们可以避免这种依赖
• WebKit IPC 是我们想要用于通信的
• Web 进程在分配缓冲区时发送消息
• 当缓冲区有帧时，它会通知
• UI 进程在缓冲区渲染时通知
• 这已经在 GTK 端口上游
• WPE 现在不使用它，因为它需要一个新的 API
• 我们不需要 Wayland 合成器来共享缓冲区
• 新的 WPE API
• 我们需要它，因为我们需要一个新模型，因为要求不同
• 计划是使其成为 WebKit 的一部分
• 而不是一个外部库
• 它仍然拥有相同的用户：WPEWebKit、平台实现和应用程序
• 在这种情况下，应用程序可以选择了解此 API
• 现在将有内置平台实现
• 这与过去的库不同
• 我们将支持加载外部库
• 但我们会将涵盖大多数情况的库作为库的一部分
• 可以可选地编译它们
• drm、wayland 和 headless 将是第一批添加项
• DRM 是渲染全屏模式浏览器最有效的方式
• 我们可以进行直接扫描输出缓冲区
• 无头模式主要用于测试
• API 现在仅限 UI 进程（已编辑）
• 使其更易于使用
• 将有 API 文档，如果没有 API 符号，我们将失败
• 并且它对于大多数用例来说都很容易使用，但又足够灵活
• API 已经存在并且正在运行
• 目前的架构将 WPE 作为用于渲染和输入处理的外部库
• Wayland 平台实现了大部分接口
• 无头模式也已完成
• DRM 正在进行中，它只实现了部分输入事件
• 计划
• 我们希望从现在开始上游化补丁
• 这是一个很大的补丁
• 但它封装得很好
• 该架构已在仓库中
• 因为它已为 GTK 端口启用
• 我们有足够的代码来确信这是正确的前进方向
• 我们需要实现缺失的功能
• 我们需要审查所有文档
• 因为我们正在添加更改，所以我们需要更新
• 我们将弃用旧 API
• 但目前我们不会移除它
• 因为一些平台无法使用共享缓冲区
• 它不需要任何 API 或 ABI 版本碰撞
• 使用旧 API 的应用程序将继续正常工作
• 但他们可以使用新构造函数使用新 API
• 准备好后就会发布
• 我们没有截止日期
• 我们有一个内部 rebase 的分支
• 它将通过构建标志上游化
• 这样我们就不会破坏任何东西，分销商也不会在它准备好之前发货
• 问题

无

• Gstreamer WebRTC 状态

幻灯片

备注

时间线简要总结 (libwebrtc, …)

• 2015-17 …
• 2017-2019: LibWebRTC 尝试
• 捆绑在 WebKit 中用于 Apple WebKit 端口.. 与 GStreamer 编码器集成，需要自定义解码器/接收器的硬件加速支持
• 2019 年至今：新的 GstWebRTC 在 GSTConf 上宣布
• 2017 年，以及我们于 2022 年上游了一个后端进行初步实验
• 当您想捕获麦克风或视频时进行屏幕捕获。在 WebKit 中，这需要从 UI 进程到 Web 进程的权限
• 我们与 Apple 端口有所不同，我认为 Apple 是在 GPU 进程中完成的
• 我们必须从 WebKit 进程到 UI 进程设计 RPC
• 这意味着目前不易测试
• 我们有一些基础设施，它偶尔会崩溃，修复起来不难，但你必须留意它
• 每个捕获设备一个管道
• 流捕获 (getDisplayMedia()) - 我们有两层权限
• 在 Linux 中，我们有 WebKit 权限请求 + 桌面门户 - 我们必须通过 IPC 与它通信
• 桌面门户可以记住以前的权限请求，所以也许我们可以改进
• 然后我们有另一个依赖 pipewire 的管道，它现在部署在 Linux 桌面上，可以捕获——它提供 DMABufs
• 对于 MediaStream 处理 - 当您需要捕获时，在 gstreamer 端口中，我们有一个插件能够将来自媒体流的数据馈送到管道中
• 我们经常使用它来处理传入流、画布/视频/捕获
• {显示一个简化的图表}
• webrtcbin 实现了 JavaScript 会话建立协议，与 webkit 的集成非常容易 - GstPromis 与 webkit 的 Promise 紧密相连
• 当您收到媒体流时，在 javascript 中，您通常会将其连接到视频元素（作为 .src） - 在 webcore 中，它将内部挂接到 webkitmediastreamsrc -
• 所有这些都意味着我们用同样的方式处理视频等正常播放——这我认为与苹果端口又有所不同
• 附加 API：不能做规范要求的所有事情，我们上游添加了一些——我们必须做一些管道工作来提供帧编码、比特率等
• 同样在 DataChannel 方面——我们不得不在 Gstreamer 中打一些补丁，但现在它集成得很好
• 我们通过了大约 60% 的测试，但这并非 WPT
• 显然还有工作要做，但我们正在接近目标
• 我们也在专门启动特定平台——我们专注于与亚马逊 Luna 的游戏——我们遵循了 Chrome 的方法，我尝试使用 Safari UA，但它不起作用……所以我们必须发送 Chromium UA 并依赖一些旧版 RTC……
• 我们有一个拉取请求，尚未被审查
• 我们遇到了一些问题，服务需要某些 Chrome 特定规范——我们提供了一些这些规范的垫片实现，只是为了让我们能够继续前进——这不太好
• 我们正在推出的另一个是 Jitsi——不幸的是它还没有工作。
• 它需要我们尚不支持的功能：重新协商、联播等
• 总结：每个平台都需要专门的启动。我们可以符合规范，但每个平台都需要更多……符合规范只是 webrtc 的冰山一角
• 关于编码——我们必须提供联播——GSTWebRTC 有一些支持，但 WebKit 尚未使用……
• 有两种可扩展性
• 关于隐私和安全……我们所有的管道都在 Web 进程中运行，我们不能将其投入生产，那很糟糕
• 理想情况下，路线图上的计划是将其转移到受限制的网络进程
• 等等
• 另一个问题涉及捕获设备——Web 进程中也存在同样的问题……初步计划是改进 GTK/桌面上的权限/门户。我们必须在用户输入可能不足的嵌入式设备上解决这个问题。然后我们希望将所有 GStreamer 管道移动到 GPU 进程
• 然后我们还有一些缺失的功能待办事项
• ICE 候选过滤
• SFrame 加密
• 改善统计覆盖率
• 收发器方向变化
• DTMF？
• 问题

如何加速视频？是否有许可问题？

• 在 adb 平台上，支持由第三方提供商 GCMA 插件提供，您可以使用该插件，因此它确实取决于具体情况
• 第二个问题：您提到了云游戏的键盘。您有没有计划将该实现上游化？
• 我认为目前苹果没有积极信号。我们可以提供一个实现，但默认情况下必须禁用它，因为与该规范相关的一些问题我们尚未解决
• 确实
• 问题是关于键盘锁定的，特此声明。
• WebKitGTK 和 WPE 端口 SDK

幻灯片

备注

flatpak 是我们之前的尝试

• 它给 WebKit 的工具链增加了太多复杂性
• 它的不可变沙箱阻止了对系统库的操作
• SDK 镜像太复杂，难以生成
• flatpak 主要用于桌面应用程序
• 新尝试是基于 Ubuntu 23.04 的容器
• 目标：尽可能地减少阻碍
• 提供与 podman 容器交互的脚本
• 3 个命令：wkdev-create、wkdev-enter，然后在新的 shell 中，可以使用 build-webkit 等常用脚本
• WebKit 的工具链无需修改
• SDK 支持使用 sccache 进行分布式构建
• 还有 VSCode 集成
• 还有 NVIDIA 工具，以及使用 jhbuild 构建系统库的脚本
• 计划是在 EWS 机器人中部署此 SDK（暂无时间表）
• SDK 源码将很快在线发布
• Github Codespaces 也可以用于从浏览器进行 WPE 开发
• 也可以在虚拟机中使用，例如在 macOS 上
• 问题

LBSE 状态

• Gstreamer WebRTC 状态

幻灯片

备注

介绍挑战、现状和路线图

• 自 2001 年开始从事 KHTML 工作
• LBSE 是 WebKit 中一个新的 SVG 引擎，利用了层树
• ……这曾经是 SVG 无法访问的，导致了一长串 Bug
• LBSE 旨在集成 SVG、HTML 和 CSS
• 尝试将 HTML 嵌入 SVG 导致了一些非常令人讨厌的 Bug；LBSE 应该能解决这些问题
• 由 Igalia 开发，并由 Igalia、Vorwerk 和现在的 WIX 资助
• 我们希望重用 WebKit 的代码路径，这些代码路径为我们提供了硬件加速，特别是透视变换
• 这些路径目前是互斥的
• 当我们开始时，只有 SVG 具有转换和其他 CSS 多年来从 SVG 中获取的功能
• SVG 渲染保持不变，而 HTML+CSS 则得到了开发
• 因此，唯一合理的更新方式是移除旧的 SVG 引擎，并用更好的引擎（如 LBSE）替换它
• 性能大致持平，MotionMark 上下降 2-4%
• 一些独立测试比以前快得多，另一些则有所下降
• 这是如何实现的？
• SVG 允许参与层树
• 移除仅 SVG 的变换、剪切、标记、遮罩、滤镜代码
• 重构 SVG 的渲染树以供 CSS 访问
• 尽可能多地重用 RenderLayout 中的代码
• 我们使用 RenderLayout 越多，免费获得的东西就越多（z-index 等）。
• LBSE 被设计为旧 SVG 引擎的直接替代品
• 这没有得到很好的反响；变化太快太多
• 所以我们不得不重命名整个旧引擎，以便它可以与 LBSE 并行存在
• 我们上次检查时，LBSE 补丁大约有 40MB
• 我们提供了一个编译时标志，允许在引擎之间进行选择
• 问题于 2021 年提出，尚未完成
• 总体进展状态约为 77%
• 主要缺少的是资源
• 自去年 WKCM 以来，许多补丁已落地
• 2022 年 11 月，我们提交了一个补丁，统一了几何和变换计算与 CSS 的关系
• 性能的关键是绕过 WebCore
• 访问已合成的图像并移动它们。
• 这让我们最终在今年开启了加速变换
• 该补丁于 2023 年 6 月落地
• 我们仍然存在重绘问题；如果您在 SVG 内部使用 CSS 进行动画，查看 Web Inspector 会导致大量重绘
• 这已于 2023 年 10 月修补
• 我们于 2023 年 9 月开始上游资源
• 在 SVG 中，资源包括剪切、遮罩、滤镜等。
• 在我们的下一步中，我们希望完成上游化，包括许多添加缺失布局测试的补丁
• WebKit 中的资源失效机制自始至终都是有缺陷的
• （显示示例，幻灯片 20/32）
• 失效实际上是如何工作的：如果你将圆的半径改为 20，剪裁器必须通知遮罩器它正在使用的矩形已更改
• 以前，我们通过布局来处理
• 因此，半径的变化会强制遮罩重新渲染
• 以正确的顺序执行，您可能会幸运地获得正确的失效
• 如果顺序错误，则不会正确发生失效
• 因此，我们遭受了大量不必要的重绘和重新布局的痛苦
• （显示示例，幻灯片 22/32）
• 这是一个典型的代码图
• 在某个时候，我们会告诉核心布局是脏的
• 我们必须使它失效
• 之后，有些东西正在将其标记为失效。为什么？
• 在某个递归调用点，元素会收到样式更改通知
• 我们必须标记该剪切路径的用户为“需要布局”
• 链中的资源会收到通知
• 如果你以正确的顺序处理但交换了元素，那么布局之后，事情仍然是脏的，所以当我们认为布局完成时，它还没有完成
• 我们认为如果我们停止滥用布局，就可以避免这种混乱
• 这一切都是我们需要避免的根本缺陷
• 失效取决于元素顺序，它不应该这样
• 我们的计划：LBSE 将无状态地进行遮罩和剪切
• 不再有临时缓冲区或单个渲染对象的缓存
• 这正在通过 RenderSVGResourceContainer（一个新的基类）实现，该类于本月（2023 年 10 月）落地
• 下一个目标是资源剪裁器
• 我们正在重写整个资源失效逻辑
• SVG 资源缓存将移至 LegacySVGResourcesCache
• 中期计划：完成对 的支持
• ，然后添加，线性和径向渐变，，和所有这些在完成 之后都变得微不足道
• 今年应该完成最初的基本实现
• 长期计划：完成 LBSE，使所有布局测试通过且不慢
• 我们必须减少核心 RenderLayer 的开销并缓存更多 SVG 子树信息
• 此外，仅在必要时选择性地构建渲染层
• 默认切换到 LBSE 并移除旧引擎的目标是 2024 年
• Igalia 正在全力以赴，将我们拥有的所有东西上游化，这样我们就能将所有东西上游化，尽管性能可能不如旧版本
• 然后我们将与 Apple 合作，以达到性能目标，并达到或超过旧引擎的性能
• MotionMark 是一个很好的例子，它没有从新引擎中受益
• 在其他测试中，LBSE 的性能比旧引擎高出几个数量级
• 问题

Sayeed：你提到你要去掉缓冲区。你如何在没有它们的情况下提高性能？

• Nikolas：这个想法是根本不必绘制这些东西
• ……如果有什么地方我们需要做更多工作，我们就会做，但这与 HTML 或 CSS 没有什么不同
• ???：你说 MotionMark 正在测试一些没有好处的东西，所以你只是用它来确保没有退步
• ……有什么现有基准能显示出这里的好处，或者你使用什么？
• Nikolas：我们目前没有任何公开的
• ……最好发布这样的基准供大家参考
• ???：我想知道您是否会在其他现有基准中看到好处
• 垂直表单控件

幻灯片

备注

写入模式指定为 vertical-rl 或 vertical-lr 的表单控件

• 导致备用 CSS 块模型表单
• 动机：缺乏国际化，互操作 2023 表单焦点区域（WK 得分最低）
• 实现：不像指定写入模式那么简单
• 示例：进度条，即使在垂直模式下也被强制具有水平样式
• 我们需要确保我们正在使用 CSS 逻辑属性，更新我们的用户代理样式表
• 布局：重新实现自定义渲染器，基线调整（自定义基线已更新以适用于垂直文本）
• 任何端口都可以通过检查渲染样式或控件样式状态来检测垂直写入模式
• 实现：渲染：旋转
• 我们只需旋转控件以匹配写入模式
• 实现：渲染：逻辑坐标
• 转置矩形、大小和坐标
• 多选演示
• 完全重写选择控件以支持水平滚动、键盘选择和 scroll-left 属性。所有端口都将从中受益
• 在端口中启用此功能：VerticalFormControlsEnabled 设置（计划在 macOS 和 iOS 中启用）
• 短期内仍有一些小的渲染问题需要解决，长期来看，需要支持弹出/原生 UI
• 问题

问：其他浏览器也不旋转复选框吗？

• 答：没有浏览器旋转复选框、单选按钮等。
• 瀑布流布局

幻灯片

备注

Jen Simmons 在 WWDC 上概述了 Masonry 布局。

• 网格：由行和列组成。这可能会在单个单元格中留下大量空白。
• Masonry：通过取消行来解决这个问题。
• [显示一个包含 7 个同级元素的示例，其中前三个元素在第一个概念行中彼此相邻。之后的元素被放置在最短的后续概念行中。]
• 致力于更新规范以使其最终确定。致力于 Align Tracks 和 Justify Tracks，由于存在大量复杂性和可访问性问题，这些已被删除。
• 固有轨道尺寸变化：我们过去使用第一个概念行来确定尺寸。这使得 Web 开发者难以使用。
• 在新规范中，所有元素都参与确定轨道尺寸。
• 问题

Speedometer 3

• Gstreamer WebRTC 状态

幻灯片

备注

用于优化和比较浏览器性能

• 2014 年 Apple 发布 1.0
• 2018 年 Apple 和 Google 合作发布 2.0
• 2022 年发布 1.2
• 2.0 主要是更新框架，与运行器或测试工具无关
• ……但它通常被认为是最受欢迎的基准测试之一
• 开放治理模式
• Speedometer 3
• Apple、Google、Mozilla 之间的合作
• 更新框架，但也包含其他类型的内容
• 不是由 WebKit 贡献策略，而是基于共识模型
• 更新的框架列表，新增（web components、svelte、lit）。已退役（ember、inferno、elm、flight）
• 新的新闻网站测试（Next.js、Nuxt.js），模拟 CNN 等网站
• 富文本和代码的编辑器测试用例
• 图表（observable plot、chart.js、stockcharts、perf dashboard）
• 已经工作了一年多
• WebKit 优化。自今年 7 月开始改进
• 持续到明年年初预定发布（2024 年春季）
• 问题

问题：在 browserbench 上运行 Speedometer 时，会影响测试最终用户的连接。有没有办法避免这种情况？

• 回答：我们得研究一下
• 问：您希望在未来版本中加入什么，或者是否有其他基准？
• 答：最大的一个是关于 Promise / Worker 的异步任务
• 问：图表是基于 SVG 的，这正确吗？
• 答：是的，有些使用 SVG，有些使用 Canvas
• 问：您如何选择框架？
• 关于网络速度问题，在 Speedometer 3 仓库中提交 GitHub Issue 是记录该反馈的好方法
• 答：我们查看基于真实网站中使用的数据，并使用当前流行的
• 或那些看起来越来越突出
• @Nikolas Zimmermann 我们有一些基于 speedo3 的 SVG 优化（主要是 attributeChanged 内容）
• 两个图表 SVG 测试是 Observable Plot 和 React Stockcharts SVG。ChartJS 和 Perf Dashboard 是 canvas
• 其他测试中散布着 SVG（例如编辑器工具栏中的图标），但我预计这不会被大量测量
• 所有字体特性（提案）

幻灯片

备注

Web Inspector 的近期贡献者。我作为前端工程师有很多经验。

• 今天我将介绍一项适用于 Web 的“所有字体”功能。
• Frances 开玩笑说字体使用不当。
• 有些字体不适合。
• 《纽约时报》使用一种特殊的字体来传达其身份。
• 我创建了一个网站，每个单词都使用不同的字体。
• Web 开发者如何查明每个单词正在使用哪种字体？
• 您可以通过检查每个元素来完成此操作吗？
• 您可以查看样式下的 font-family... 但您无法知道实际选择了哪一个。这不清楚。
• 然后您看到 Times New Roman，但它是默认字体，所以仍然令人困惑。
• 您还可以查看 CSS 本身，看看通过 ID 应用了什么
• 以及通过类
• 您最后的选择是使用 Firefox 及其开发工具。但这仍然无法告诉您 WebKit 选择了哪一个。
• 提案：如果您有一种方法可以通过新的字体选项卡查看选择了哪种字体，那会怎么样？
• 挑战：如果您有一个幻灯片，例如，每张幻灯片使用不同的字体，或者脚本正在更改内容，或者计算样式在不同设备上不同，那该怎么办？
• 现在，我已经设法在 console.log() 中显示正确的信息。
• 问题

问题：您能否跟踪某个元素正在使用哪种字体？

• 现在我只会展示网页上一个元素的所有计算字体
• Playwright 与现代端到端测试现状

幻灯片

备注

将讨论功能、趋势、挑战等

• 团队最初在 Google，在分叉前从事 web inspector，分叉后从事 chrome devtools
• 后来是 node.js 调试
• 某时 Puppeteer 作为浏览器自动化接口出现
• 后来专注于 Web 测试
• Playwright 测试示例，类似于布局测试，隔离环境
• 在跟踪查看器中逐步查看测试执行
• 独特功能：一键安装
• 在 3 个操作系统、云端、有头和无头模式下工作
• 浏览器白盒检测、网络拦截、忽略 TLS、Workers 等
• 可靠的测试是优先事项
• 每个测试都在干净、隔离的环境中运行（每个测试一个新的一次性上下文）
• 并行测试执行
• Chromium、WebKit、Firefox 开箱即用
• Linux 主导 CI
• 因为它在云中更便宜
• 主要是 Node.js，Python 远远第二
• 也支持 .NET 和 Java
• 主要参与者的下载统计
• Cypress：测试在页面内运行，不支持 oopifs
• 出色的用户体验使其成为领导者
• Puppeteer：Chromium 的进程外 CDP 客户端，浏览器的通用 API
• Playwright：上升趋势，相对较新
• selenium-webdriver：下载速率稳定
• 每个工具都使用自己的方式连接到浏览器
• 只有 Playwright 是跨浏览器的
• Playwright 安装的默认浏览器下载统计
• Firefox 和 WebKit 各占很大份额
• 集成上的整体方法：从浏览器检测到重试
• 对所有 Bug 负责，不对其他组件指手画脚，如果浏览器协议存在 Bug，则被视为 Playwright 的 Bug
• 浏览器修复要么上游，要么下游
• 在 Chromium 中，一切都是上游的
• WebKit：Wincairo、Linux wpe（无头）和 gtk（有头）、macos
• 支持所有平台上的无头执行
• 实现为 Web Inspector 代理
• 协议足够丰富，涵盖了我们需要的所有实体
• 找不到其他提供可比功能的协议
• 在测试网站如何在移动 Safari 上运行时，我们需要模拟触摸
• 代码是 iOS 特定的
• 固定布局模拟也是如此
• 合成后截屏是跨平台的一个挑战
• Web Driver 中也存在同样的问题
• 网络栈在不同平台之间不同
• 将 Web Inspector 协议更改上游化没有充分的理由，因为其中许多更改不能直接被 Web Inspector 前端使用
• 问题

标准立场页面与贡献

• Gstreamer WebRTC 状态

幻灯片

备注

GitHub 上有一个仓库，WebKit 用它来征求和提供 Web 标准的反馈

• 旨在与实际实现分开
• 有时不得不实现 WebKit 不喜欢的东西
• 理想情况下，允许以更原则/概念性的观点评估标准
• 协作可以是异步的
• 要请求立场，与同事讨论，发布评论询问，设定截止日期，并且 (通常) WebKit 会在此之前做些什么
• 还有一个基本网站，用于可视化 GitHub 上标准立场仓库的状态，并带有一些额外功能（例如搜索、过滤等）
• 希望有更多贡献者。通常只有 Apple 员工
• 可以在应用标签到问题上提供帮助。有些是自动化的，但并非全部。所有贡献者都应该能够做到
• 工具和网站有改进空间
• 问题

问：来自实际用例的意见常常缺失于标准立场中

• 答：更多这样的意见肯定会有用。有些情况下确实发生了，但并不常见。可能是 Web 开发者本身没有参与。WebKit 应该鼓励他们
• 问：有没有标准立场存在分歧的例子？“内部”分歧可能会稍微阻碍标准工作的发展势头
• 答：有一些与更广泛的 Web 社区存在分歧的问题，但 WebKit 内部并不常见。可能邮件列表过去有更多“内部”分歧。如果有更不公开的讨论，例如您想在公开发布之前“征求意见”或验证观点等，可以使用 #standards/#standards-github slack 频道
• 在 JSC 中实现 WebAssembly GC 提案

幻灯片

备注

这个提案是什么以及为什么你在这里？

• Wasm 是一种用于编译 Web 程序的语言。它是 JS 的替代品，用于转译
• 它已被用于许多有趣的应用程序——将 Photoshop 带到 Web 上，使用这种方式编写插件的东西——飞行模拟器，游戏
• 你可能会想：难道它只能用于那些低级的东西吗？
• wasm——它能被使用 GC 的语言使用吗？
• 笨拙的解决方案，但关键的缺失部分是某种可分配的内存——这就是这个 GC 提案的目的
• 它具有结构体和数组等数据类型
• 以及新的引用类型——从中可以获得新的类型转换和高级类型
• 至少在浏览器环境中，它被设计为利用已有的内置功能
• （显示一个带有类型声明的具体示例）
• （以及用新类型初始化的全局变量）
• （以及访问该数据的写入操作）
• （和新的引用类型）
• 还有更多功能，但这只是一个高级概述
• 我们来谈谈 JSC 中的实现进展
• 提案的大部分功能已经实现
• 但它还不是一个可发布的状态——还需要几个月——批量数组操作尚未实现，还有一些缺失的指令——它需要更多的测试和优化，但看看已经实现了多少（很多）
• 基本上：它进展顺利，希望我们能尽快发布。
• 最大的收获是，这对 WebAssembly 来说是一个激动人心的时刻——这项提案使得 WASM 能够用于更多语言。它处于阶段 4，几乎是最后一个阶段——它已在其他浏览器中发布
• 它使得 WebAssembly 能够针对 Java、OCaml 和许多其他语言
• 问题

在 Windows 端口上启用 WebAssembly 和 FTL JIT

• Gstreamer WebRTC 状态

幻灯片

备注

大家好

• Windows 上的 wasm 工作
• 询问关于资源中心的问题
• 为什么要改进 Windows 端口？
• 首先，Playwright 提供了在 Windows 上测试 WebKit 的经验
• 其次，Bun 使用 WebKit Windows 端口
• 有利于端口对齐
• 与 gtk 或 wpe 相比，Windows 上的功能不同
• 对于项目来说，实现跨平台桌面应用程序将是非常棒的，目前被 Electron 垄断
• 这意味着 Chromium
• 其他项目正在使用系统 webview 来实现此功能
• 因此，WebKit 在 Windows 上的受限功能限制了许多开发人员的选择
• 更多项目希望将浏览器带到 Windows
• 从在 Windows 上处理信号处理器开始
• 已于五月落地，使用异常处理器
• 下一步：启用低级解释器
• 目前有一个开放的 PR，使用了一些 DLL 魔法
• PR 正在开放征求反馈！
• 当前状态大致与 Safari 对 WASM 的支持相匹配
• JIT 除外
• JIT 已经工作到支持 ARES-6 的程度
• 还有一些已知问题
• 作为额外好处，将解锁 BBQ 和 OMG JIT
• ARES-6 显示 JIT 带来了性能提升
• 下一步
• 落地进行中的 PR
• 处理静态断言，这将使启用某些功能变得更容易
• 性能方面还需要更多工作
• Windows 端口性能与 Mac 端口之间存在巨大差异
• 交叉编译，可能在 Wine 下运行
• 有兴趣为这项工作获得报酬，如果您有兴趣，请在 Slack/电子邮件上联系我！
• 感谢一路上所有提供帮助的人！
• 问题

向客户交付 Web API

• Gstreamer WebRTC 状态

幻灯片

备注

在 Web 上首次正确发布 API 非常重要——您无法取消发布。一旦 Web 开发者开始使用它，它就会保留下来

• Web 没有版本 2。“有 Web，还有更多的 Web。”它是一个增量平台
• 互联网没有版本2。“只有互联网，以及更多的互联网”。它是一个增量平台。
• “Web 2.0并非真正存在。只有互联网，以及更多的互联网。” 经典之言。
• 在设计API时考虑开发者体验。它是否简单/直观？与其他API的一致性如何？它如何与其他API交互？该API是否会对最终用户产生意外行为？
• 对在制品（或已完成）规范提供反馈对规范编辑者非常有帮助——请提供反馈。
• 作为实现者，这本身就是工作的一部分，而不仅仅是将规范翻译成代码。
• 在构建Web API时，制作演示（与测试用例不同）很有帮助。展示开发者将如何实际使用该API。展示最终用户体验会是怎样的。
• 这有助于传达您所构建内容的价值。
• 制作演示有助于发现API设计中的缺陷。
• 步骤2：测试您的实现。
• Web平台测试很棒，应该是流程的一部分，但您应该确定它们是否与规范匹配，以及是否详尽。所有情况都覆盖了吗？
• 例如：对于布局，有时有很多未覆盖的边缘情况，比如将某个东西放入过小的容器中。
• 添加一个功能标志。
• 参见 UnifiedWebPreferences.yaml。
• 这些最近已进行了彻底检修，并提供了文档以指导使用。
• 衡量您的实现质量。
  • WPTs
  • 互操作性
  • 性能和功耗
  • 您的演示效果如何？
• 在STP中测试，而不仅仅是迷你浏览器。自动填充等功能可能会引入迷你浏览器中不存在的意外交互。
• 在iOS上测试（如有需要，与Apple合作）。
• 确保规范与实现保持一致。如果实现不一致，且无人提出异议，用户和开发者都会受损。
• 测试您的演示。
• 您应该努力交付三样东西：
  • 功能
  • 测试
  • 规范更改/改进
• 如何在Safari中切换功能标志？
  • 启用调试菜单（在线文档有说明）。
  • 前往“功能标志”部分，应该能找到带有切换按钮的标志列表。
• 您的功能发布后可能的一些后续工作。
  • 网页开发者工具（例如在Web检查器中）。
  • 供WebKit开发者使用的WebKit调试工具。

问题

• 演示不仅有助于指导您的功能开发，还有助于推广和帮助开发者学习新的Web技术。如果您有值得展示的内容，可以联系@Jen Simmons 或 @jond。
• 问：我们能否在webkit.org上放置此类演示？
• 答：webkit.org/demos。也经常嵌入到网页/帖子/发布文章中。请联系Jen或Jon寻求帮助。
• 问：如果规范处于孵化期怎么办？是否适合开始上游实现？即规范尚未准备好，仍在进行更改。
• 答：这取决于情况。规范预计会改变多少？
• 举一个具体的例子，CSS Grid经历了多次迭代。微软最初的一个实现有助于指导改进。一旦规范最终稳定下来，更多的实现者才加入进来。
• 在这种情况下，早期实现确实非常有帮助。
• 不同的实现者可能对规范有不同的解读，这有助于揭示歧义，最终为所有人创建一个更强大的Web平台（已编辑）。

兼容性补丁：Web的金缮

幻灯片

备注

• Web上很多东西由于多种原因而出现问题，导致负面的用户体验。这可能是由于网站/库针对特定浏览器，新功能，旧功能被移除，网站依赖的错误修复，或跟踪预防。
• 这些问题可以通过用户代理覆盖（谎报您的身份，例如修改用户代理或HTTP头部）、C++兼容性补丁（在代码层面进行实现）以及网站上的热修复来纠正。
• 第一个推出网站热修复的浏览器是Opera BrowserJS（Blink之前），它通过在加载后修改JS/CSS内容来实现。
• Source/WebCode/page/Quirks.cpp 是一个主要基于域名和简单启发式方法的布尔（真/假）文件。实际的兼容性补丁逻辑位于C++代码库的其他地方。
• 兼容性补丁的实践示例：ikea.com曾遇到一个问题，即在WebKit更改后，页面底部的图片无法加载。WebKit推送了一个兼容性补丁，针对该特定网站执行了特定的、不同的行为。宜家随后修复了该问题，此时该兼容性补丁被移除。
• @Brandon 实现的兼容性补丁位于：https://github.com/WebKit/WebKit/pull/6595
• @Karl Dubost 移除的兼容性补丁位于：https://github.com/WebKit/WebKit/pull/14058
• 对于用户代理覆盖：HTTP User-Agent + navigator.userAgent。
• 源代码位置
  • GTK：Source/WebCore/platform/glib/UserAgentQuirks.cpp
  • Firefox iOS：https://github.com/mozilla-mobile/firefox-ios/blob/main/Shared/UserAgent.swift
  • Safari（通过WebKit）
    • WebKit用户代理覆盖API
    • 更多信息请参阅此错误报告。
• 问题
  • 兼容性补丁不“干净”！它们修改了C++代码库。
  • 它们是“全有或全无”的，意味着它们要么全部开启，要么全部关闭。
  • 从编写兼容性补丁到发布之间存在很长的延迟（用户体验受损）——对外沟通耗时，有时还不成功。
  • 网站在想要更改时，可能会最终被兼容性补丁阻碍。
  • 我们并不总能收到网站何时修复的通知——那它（兼容性补丁）是否仍然需要？
• 我们如何最大限度地减少用户的痛苦？
  • 更简单的配置（plist/JSON/声明式？）
  • 为网页提供特殊的强大原语（可能对安全和代码注入攻击造成灾难性后果）。
  • 动态兼容性补丁/用户代理覆盖（自动停用的）。
  • 允许WebKit GTK/Firefox iOS使用它们吗？
  • 允许比域名更细致的特异性。
  • 独立于发布版本的更新机制（Opera BrowserJS）。
  • 用于移除兼容性补丁的手动QA/测试套件（例如Firefox/Opera）。

问题

• Gstreamer WebRTC 状态