Firefox 和 Chrome 应用程序清单的主要区别是什么

Question

FF 和 Chrome 都开始支持使用应用清单和服务工作者的渐进式网络应用。

那么在编写清单时要牢记哪些主要区别（或者同一个清单文件可以同时用于两者）。

如果是托管的 webapp（不是打包的），在让用户安装它的过程中有什么不同？

Answer 1

这个问题有很多内容。我将尝试通过提供一些历史记录来解决所有问题，然后回答 OP可能提出的几个问题。

背景

打包应用

Chrome、Firefox、Opera 和许多其他平台在不同时期都有“打包”的应用程序平台，这些平台运行 HTML/JS/CSS 内容但不在网络上。这些通常使用某种清单文件与类似 zip 的打包和目录结构（有时是签名）相结合来分发应用程序。这些应用程序通常不参与同源策略或以与 Web 内容相同的约束和功能运行；通常，这些软件包是通过专有商店提供的，并且功能功能和 API 还不能用于“普通的旧网络内容”。

这些应用程序的清单格式（至少在Chrome Packaged Apps 和Firefox Packaged Apps 的情况下）是一个内容和选项未标准化的 JSON 文件。

托管应用

一些系统已将为其专有的打包应用程序系统提供的额外功能与“真正的”基于 Web 的应用程序托管相结合，以创建“托管应用程序”。它们有多种形式，但 TL;DR 是它们也倾向于以基于 JSON 的专有清单文件为特色。例如，请参阅 Chrome Hosted Apps、Firefox Hosted Apps 和 Windows 10 Hosted Apps 的文档。

同样，这些系统是专有的、非标准的和不可互操作的，尽管有问题的内容来自“真实网络”（不像它们的打包应用表亲）。

渐进式网络应用

Progressive Web 应用程序与打包应用程序和托管应用程序的不同之处在于它们只是“普通的旧网络内容”，也碰巧指向基于清单文件在标准轨道上Web App Manifest format。

这种格式是 Chrome 检测并用于触发“Add-to-Homescreen”行为的格式，当您手动向主屏幕添加内容时（以及将来 Opera 提示时），Opera 当前使用该格式。

Mozilla 为这种格式提供了signaled support，他们的工程师已经大量参与了标准的设计和演变。我很乐观，这将演变为对基于标准而非专有清单的 UI 的支持。

Mozilla 还有望在未来几个月内提供对 Service Worker 的支持，这将为 Chrome、Opera 和 FF 之间的可互操作“安装”行为奠定基础。激动人心的时刻。

Answer 2

有两件事在起作用：传统和未来。

Legacy 部分（因为缺少更好的短语）是旧式包装系统（尽管它们仍然可以正常工作）。 Mozilla 和 Chrome 都有自己的打包格式和大致相似的 JSON 清单。我个人会远离这两者并专注于未来。

面向未来的系统Web App Manifest 受 Chrome 支持，用于 Android 上的安装体验。 Opera 和 Firefox OS 也支持它。您在两者上编写的清单应该适用于所有平台。显然每个实现都处于不同的阶段，例如：

• Chrome 有 chrome_related_applications 和 prefer_related_applications 用于链接到本机应用程序
• Chrome 支持 background_color 和 theme_color 生成启动画面
• Firefox 需要一个 splash_screens 对象来创建启动画面。
• Firefox 定义了一个scope，它告诉浏览器 URL 路径被认为是应用程序的一部分。 Chrome 和 Opera 忽略了这一点。

我会说 Web App Manifest 现在至少为可安装的 Web 应用定义了一个“一致”的愿景。