视频的画中画支持是我们在 Firefox 桌面版中推出的功能,适用于 Windows 用户的 71 版本,以及 macOS 和 Linux 用户的 72 版本。它允许用户将 <video>
元素拖动到一个始终置顶的窗口中,以便他们可以切换选项卡或应用程序,并且始终可以看到视频 - 比如,如果你想一边观看体育比赛一边工作,这个功能非常有用。
像往常一样,我们设计和开发此功能时以用户代理为中心。具体来说,我们希望让用户能够轻松地控制他们在 Firefox 中观看视频内容的方式。

在接下来的几节中,我们将讨论我们如何设计此功能,然后深入了解实现细节。
设计过程
回顾过去,展望未来
为了开始我们的设计过程,我们回顾了过往。2018 年,我们推出了 Min-Vid,这是我们的 测试飞行员实验 之一。我们提出了一个问题:“我们如何最大程度地从 Min-Vid 中学习?”。感谢出色的 Firefox 用户研究团队,我们拥有足够的先前研究成果,以了解用户体验中的主要痛点。但是,必须承认,自 2018 年以来,竞争格局发生了很大变化。用户和 其他浏览器 如何解决这个问题?用户对这些解决方案有什么看法,我们如何改进它们?
我们从一开始就秉持两个重要的指导原则
- 我们希望将此功能转变为以用户为中心的特性,并使其适用于网络上任何类型的视频内容。这意味着实施 画中画 规范不是一种选择,因为它需要开发人员先选择加入。
- 鉴于它可以用于任何视频内容,因此该功能需要尽可能地易于发现和使用。
牢记这些原则,有助于我们评估所有不同的解决方案,并且对于下一阶段至关重要。

尝试,再尝试
在了解了其他人如何解决问题之后,轮到我们尝试了。我们希望确保可发现性,而不会让功能变得侵入性或烦人。最终,我们希望增强 - 而不是破坏 - 观看视频的体验。我们绝对不想对任何流行的视频播放器或平台造成问题。

这促使我们使用 Framer X 构建了一个基于交互式动画的原型。我们的原型提供了一种非常有效的方式,可以从真实用户那里获得早期反馈。在测试中,我们不仅关注可用性和可发现性。我们还花时间重新了解用户面临的问题。我们学到了很多东西!
我们第一项研究的参与者赞赏此功能,虽然它确实为他们解决了一个问题,但他们很难自己发现它。
因此,我们卷起袖子,再次尝试。我们知道我们要追求什么,我们现在对用户的基本期望有了更好的了解。我们探索、集思广益、讨论技术限制,直到我们找到了一个既能提供可发现性又不会造成干扰的版本。在那之后,我们花了几个月时间来完善和优化最终体验!
敬请关注
从一开始,我们的用户就参与到了对话中。早期和持续的用户反馈是产品设计的关键方面。当我们 与您等用户互动以获得您的反馈 时,将画中画功能保留在我们的 Beta 通道中尤其令人兴奋。
我们倾听,您的帮助让我们发现了在设计和开发过程中可能错过的盲点。在设计过程的每个阶段,您都在场。 并且您现在仍然在。感谢您!
实现细节
Firefox 画中画切换按钮位于与内置 HTML <video>
控件相同的特权 阴影 DOM 空间内,在 <code><video>
元素中。由于 DOM 的这部分对于页面 JavaScript 和 CSS 样式表是不可访问的,因此网站更难检测、禁用或劫持该功能。
进入阴影 DOM
然而,在早期,当我们使切换按钮在悬停时可见时,我们遇到了挑战。网站通常会以这样的结构构建其 DOM,即鼠标事件永远不会到达用户正在观看的 <video>
。
通常,网站会在 <video>
元素的顶部放置透明节点。这些节点可用于在视频开始播放之前显示底层视频的预览图像,或用于提供插播广告。有时,透明节点用于仅在用户将鼠标悬停在播放器上时才会显示的内容 - 例如,自定义播放器控件。在这种配置中,透明节点会阻止底层 <video>
匹配 :hover
伪类。
其他时候,网站会明确说明它们不希望底层 <video>
接收鼠标事件。为此,它们会将 pointer-events
CSS 属性 设置为 <video>
或其祖先节点的 none。
为了解决这些问题,我们依靠网页从浏览器引擎接收事件这一事实。在 Firefox 中,我们控制浏览器引擎!在发送鼠标事件之前,我们可以检查光标正下方的 DOM 节点类型(重用为 elementsFromPoint
函数 提供动力的相同代码)。
如果这些 DOM 节点中的任何一个是可见的 <video>
,我们将告诉该 <video>
它正在被悬停,从而显示切换按钮。同样,我们使用类似的技术来确定用户是否正在点击切换按钮。
我们还使用了一些基于视频大小、长度和类型的简单启发式方法来确定是否应该显示切换按钮。这样,我们就可以避免在切换按钮很可能比不显示更烦人的情况下显示它。
浏览器窗口内的浏览器窗口
画中画播放器窗口本身是一个浏览器窗口,其中大部分周围的窗口装饰都已折叠。标志告诉操作系统将其保持在最上面。该浏览器窗口包含一个特殊的 <video>
元素,它在与原始选项卡相同的进程中运行。该元素知道如何显示原本应该在原始 <video>
中显示的帧。与大多数 Firefox 浏览器 UI 一样,画中画播放器窗口是用 HTML 编写的,由 JavaScript 和 CSS 提供支持。
其他浏览器实现
Firefox 不是第一个推出画中画实现的桌面浏览器。macOS Sierra 上的 Safari 10 在 2016 年推出了此功能,Chrome 在 2018 年底推出了 Chrome 71。
实际上,每个浏览器制造商的实现都略有不同。在接下来的几节中,我们将比较 Safari 和 Chrome 与 Firefox。
Safari
Safari 的实现涉及 <video>
元素上的非标准 WebAPI。了解用户正在运行 Safari 的网站可以调用 video.webkitSetPresentationMode("picture-in-picture");
将视频发送到本地的 macOS 画中画窗口。
Safari 包含一个用于 <video>
元素的上下文菜单项,用于在画中画窗口中打开它们。不幸的是,这需要进行尴尬的双击右键才能访问像 YouTube 这样的网站上的视频,这些网站会覆盖默认上下文菜单。这种尴尬之处在所有实现上下文菜单选项的浏览器中都存在,包括 Firefox。

Safari 用户还可以右键点击地址栏或选项卡栏中的音频指示器来触发画中画。

在较新的 MacBook 上,Safari 用户可能会注意到音量滑块右侧的按钮。您可以使用此按钮在画中画窗口中打开当前正在播放的视频。

Safari 还使用内置的 macOS 画中画 API,该 API 与操作系统中的其他功能实现了非常流畅的集成。
与 Firefox 的比较
尽管如此,我们认为 Firefox 的方法有一些优势
- 当 多个视频同时播放 时,Safari 的实现对哪个视频将在使用音频指示器时被选中有些模棱两可。它似乎是最新的已聚焦视频,但这并不立即显而易见。Firefox 的画中画切换按钮让 用户非常清楚 哪个视频将被放置在画中画窗口中。
- Safari 似乎对用户可以将画中画播放器窗口放大到多大程度存在任意限制。Firefox 的播放器窗口没有这个限制。
- 在 macOS 上,全局范围内只能有一个画中画窗口。如果 Safari 正在显示画中画视频,然后另一个应用程序调用 macOS 画中画 API,则 Safari 视频将关闭。Firefox 的窗口是 Firefox 特定的。即使另一个应用程序调用 macOS 画中画 API,它也会保持打开状态。
Chrome 的实现
PiP WebAPI 和 WebExtension
Chrome 的画中画实现主要围绕由 Google 推动的 WebAPI 规范。此 API 目前正在通过 W3C 标准化流程。从表面上看,此 WebAPI 与 Fullscreen WebAPI 类似。响应用户输入(如点击按钮),网站作者可以请求将 <video>
放入画中画窗口。
与 Safari 一样,Chrome 还包含一个用于 <video>
元素的上下文菜单选项,可以在画中画窗口中打开。

此提议的 WebAPI 也被 来自 Google 的 PiP WebExtension 使用。该扩展程序添加了一个工具栏按钮。该按钮会找到页面上最大的视频,并使用 WebAPI 将该视频打开到画中画窗口。

Google 的 WebAPI 允许网站表明 <video>
不应该在画中画播放器窗口中打开。当 Chrome 看到此指令时,它不会在 <video>
上显示画中画的上下文菜单项,并且 WebExtension 会忽略它。除非用户修改 DOM 以删除该指令,否则他们无法绕过此限制。
与 Firefox 的比较
Firefox 的实现比 Chrome 的方法有许多明显的优势
- Chrome WebExtension 只针对页面上最大的
<video>
。相比之下,Firefox 中的画中画切换功能可以轻松选择网站上的任何<video>
在画中画窗口中打开。 - 用户现在就可以在所有网站上使用此功能。Web 开发人员和网站维护人员无需开发、测试和部署新 WebAPI 的使用。这对没有积极维护的旧网站尤其重要。
- 与 Safari 一样,Chrome 似乎对用户可以将画中画播放器窗口放大到多大设置了人为限制。Firefox 的播放器窗口没有这个限制。
- Firefox 用户可以在所有网站上使用此画中画功能。网站无法通过 WebAPI 直接禁用它。这为整个网络上的
<video>
元素创建了更一致的体验,最终也让用户拥有更多控制权。
最近,Mozilla 表示我们 计划推迟 Google 提议的 WebAPI 的实现。我们想看看我们刚刚发布的内置功能是否能满足用户的需求。同时,我们将密切关注 WebAPI 规范的演变,并可能在将来重新审视我们的实现决定。
未来计划
现在我们已在所有平台上的 Firefox 桌面版中发布了画中画功能的第一个版本,我们正在密切关注用户反馈和错误收集。您的意见将帮助我们确定下一步行动。
除了错误修复,我们还希望分享一些我们正在考虑的未来功能工作。
- 当有可见的可点击元素重叠时重新定位切换按钮。
- 在播放器窗口中支持视频字幕。
- 在播放器窗口中添加一个播放头滑块来控制
<video>
的当前播放位置。 - 在播放器窗口中添加一个用于控制
<video>
音量级别的控件。
您如何使用画中画功能?
您是否正在使用 Firefox 中的新画中画功能?您觉得它有用吗?请在下面的评论部分告诉我们,或者 发推文附上截图!我们很乐意听取您对它的使用感受。您也可以 在此处提交功能错误。
关于 Mike Conley
从事 Firefox 桌面版开发的工程师
29 条评论