ios chrome开发者模式(chrome开发者模式)

以往 Safari 发布新版本，因其更新时间及更新内容的不确定性，时而都会给开发者带来一些问题，但都比不上这次 Safari 16.4 发布带来的麻烦大。

原文链接：/d/file/gt/2023-09/xkqq1zvhtuu | ASHLEY译者 | 弯月 责编 | 郑丽媛出品 | CSDN（ID：CSDNnews）

最近，Safari 16.4 的推出，对我们来说简直就是一场噩梦：我们制作了一款基于浏览器的应用。在 Safari 16.4 的早期版本上，我们不仅打不开项目，预览项目以及所有的发布内容都出了问题。

我想通过本文分享我们的经验，让客户、开发人员、监管机构以及苹果了解 Safari 的新版本给我们带来了多少困难。

大多数浏览器都提供预发布版本以供早期测试。例如，Chrome Canary 和 Firefox Nightly 每天更新，此外还有发布频率没有那么高的开发版和 beta 测试版。苹果提供了 Safari Technology Preview，但仅适用于 macOS，而且没有按照公开的时间表更新，好像是每两周一次。预发布浏览器通常都不太稳定，不过明显的问题很快就会得到解决。然而，当某个功能进入测试版后，就应该仔细研究了。因此，2 月 16 日 Safari 16.4 beta 版发布时，我们仔细研究后发现了很多问题。

我们的项目基于 zip 文件，使用流行库 zip.js 来读取，在浏览器支持的情况下，这个库会使用 Compression Streams API。Safari 16.4 添加了对 Compression Streams API 的支持，但它在某种程度上与 zip.js 不兼容，这意味着，我们的应用经常无法打开项目，也就是说网上其他使用 zip.js 的应用可能都无常运行了。

我于 2 月 17 日正式报告了这个问题，苹果工程师进行了调查并确定了问题，表示他们已在 2 月 27 日之前解决了问题。苹果的及时反馈不错，员工表现也很出色。

3 月 8 日，Safari Tech Preview 发布，依然有 bug。据说 Safari 16.4 的发布也在近期，但我们不确定，因为我们不知道具体的时间计划。我们应该怎么办？他们是否发布了修复程序？可这个问题依然存在。还是说，他们还没有发布修复程序？但距离他们修复问题已经过去一周了，为什么不发布呢？我们是否应该假设 Safari 的新版本会破坏 Compression Streams，而他们会发布紧急补丁来解决这个问题？他们肯定不会冒险破坏所有人的 zip.js，对不对？即便做出这样的假设，我们仍然不知道需要等待多久才能采取行动。难道我们要坐等 Safari 16.4 附带一个有效的修复程序？难道我们要等到 Safari 16.4 正式发布，才能知道我们是否面临灾难？这真是一个两难的困境。

我询问了苹果修复程序是否会在 Safari 16.4 中发布，然而他们的工程师在回答时却提及了 STP。不幸的是，我们的问题没有得到答复，谁也不能保证 STP 中的任何功能会出现在 Safari 16.4 中。

最后，我们决定看看 Safari 16.4 究竟会包含什么。在这期间内，如前所述，我们的大多数项目都打不开了。此外，搞清楚 Safari 新版本究竟会发布什么的唯一办法就是手动测试，这意味着我们不得不浪费时间弄清苹果早已心知肚明的信息。

经过几周的痛苦等待，3 月 23 日 STP 终于发布了，3 月 27 日 Safari 16.4 也终于推出了。这之间只隔了一个工作日，那天我干了些什么？什么都没干，因为我早就预订那周五和接下来整个星期休假了。我不知道何时休假才能避开 Safari 的新版本发布。因此，直到 4 月 3 日，Safari 16.4 发布整整一周后，我才能亲自验证实际的结果。我根本无法确定我们的软件是否可以在 Safari 中运行。值得庆幸的是，我们的软件能够在 Safari 16.4 中正常运行，也可以在 STP 166 中正常工作。

如果苹果能够像所有其他浏览器制造商一样，明确说明新版本中修复了哪些问题，所有这些困难在很大程度上都是可以避免的。只要一点点的透明度，就可以改变我们的整个计划。

我们发现的另一个问题是，预览项目显示一片空白。这对我们来说也是一个重大问题，我也提交了反馈。苹果工程师再次协助调查，并出色地完成了工作。我不打算在此赘述细节，因为整个过程很复杂，而且没有太大意义，我只想说明 Service Workers 关系到我们的预览项目，我们的代码恰巧需要依靠 Chrome的一个 bug，这意味着我们的 Service Worker 在 Safari 16.4 中遭到了破坏。所以这次的问题实际上出在谷歌，他们应当负起修复的责任。但我们又一次陷入了可怕的困境。

因为 Safari 即将发布新版本，这一次必须由我们来解决这个问题。但是，我们有多少时间呢？这是一个重要的问题。我们有自己的产品发布时间表，包括用于测试的 Beta 版本，并且每隔几个月我们就需要推出一个稳定版本。

如果我们知道 Safari 的具体发布日期，就可以比较两个时间表。如果时间宽裕，我们就不必太紧张，慢慢调查，然后在 Safari 更新之前，按照我们的正常发布时间表推进工作。但是，如果 Safari 定于第二天发布，我们就陷入了紧急情况：必须赶在第二天之间修复，以防止对客户造成干扰。这实际上是例行错误修复与紧急情况应对之间的区别。

当然，我们不知道 Safari 第二天会不会发布。一些苹果员工暗示，他们不允许谈论具体的时间表，只能说“快了”。所以，我们被迫将其视为紧急情况，并立即采取行动。更糟糕的是，Service Workers 的开发难度很大，非常复杂。因此，我们不得不暂停其他工作，按照紧急情况应对计划完成所有的工作，然后立即发布给所有客户，实际上这是有风险的，如果我们出了问题，其他功能遭到破坏，该怎么办？

如果苹果能够像所有其他浏览器制造商一样，公开发布时间表，所有这些困扰本可以避免。只要一点点的透明度，就可以为我们省去很多麻烦。幸运的是，我们的推出进展顺利，没有破坏任何其他东西，然而，Safari 缓存旧的 Service Worker 脚本的方式似乎不同于其他浏览器，这点让我们感到更加头疼。我一直不明白为什么会这样，但这有可能使情况变得更糟。

最终，Safari 16.4 在大约一个月后推出——我们本可以轻松应对，但拿不准时间开启的紧急响应，导致其他工作不必要地暂停，还浪费了时间。

最后，还有一个更大的问题。我们发现在 Safari 16.4 中，过去几年发布的所有网页游戏都遭到了破坏。

问题在于，我们的产品会使用 OffscreenCanvas（如果受支持的话） 在 Web Worker 中运行游戏，以获得更好的性能。Safari 16.4 添加了对 OffscreenCanvas 的支持，但只有 2D，WebGL 仍然不受支持。我们的产品需要 WebGL 进行渲染。所以，看到 OffscreenCanvas 得到了支持，我们的产品就会创建 OffscreenCanvas，然而在获取 WebGL 时返回了 ，于是整个屏幕一片空白。这实际上是最大的问题，大量现有的网络内容因此而遭到破坏。

我们发布了第二个紧急补丁来修复这个问题（所有其他工作再次暂停），但由于多年来我们的客户一直在网络上发布内容，因此更新所有内容基本上是不可行的。这个问题牵扯到 itch.io、Newgrounds、Poki 以及我们自己的街机等数千款游戏，此外还有企业使用的培训材料，教师使用的教材，博物馆中的交互式信息亭等等，这些都是潜在的灾难。

对此，我们大吃一惊。我们用了非常简单的方式检查 OffscreenCanvas（typeof OffscreenCanvas !== \"undefined\"）。我从没想过浏览器会支持一些上下文，同时却不支持其他上下文。我以为对于上下文的支持至少应当与标准的<canvas>元素一致，但 MDN 文档并没有提到上下文不一致的问题：Chrome 于 2018 年发布了支持所有上下文的 OffscreenCanvas；Firefox 于 2022 年发布了支持所有上下文的 OffscreenCanvas——这是第一次某个浏览器对上下文的支持不一致。

苹果指出，这是规范允许的，是我们功能检测的错。但查看相关规范，我并没有看到明确说这是允许的。姑且让我们假设这确实是允许的，毕竟，浏览器制造商对规范的研究比大多数 Web 开发人员更透彻。

首先，我研究规范的目的是保证网站的兼容性，事实上，HTML 设计原则说支持现有内容。例如，当发现新方法名 Array flatten 会破坏网站时，规范就将其重命名为 flat，从而避免破坏网站。这说明规范反映了网络的现实，而不是成为破坏它的理由。

所以，我认为首选解决方案应该是：更新规范，声明 HTML canvas 和 OffscreenCanvas 应该支持相同的上下文。这样就可以避免我们面临的网络兼容性问题（其他人也有可能面临这样的问题），看起来也更加一致。而 Safari 应该延迟发布 OffscreenCanvas，直到支持 WebGL，避免已有的网络内容受影响。

其次，即便规范是正确的，浏览器制造商也不愿修改规范，但苹果一点都不关心网络兼容性吗？为什么不延迟 OffscreenCanvas 的支持，等到添加对 WebGL 的支持，然后再一起发布呢？我相信大多数有经验的软件开发人员在职业生涯中都做过类似的决定：发现新功能有问题，你就应该关闭该功能，将其推迟到下一个预定版本，并利用这段时间修复问题。

距离 Chrome 全面支持 OffscreenCanvas 已经过去 4 年半了，Safari 才开始支持 OffscreenCanvas，结果却破坏了现有的发布内容，当然，更好的选择是在 Chrome 发布后 4 年零 9 个月，再发布完整的支持，以保证 Web 兼容性。为什么他们选择匆匆忙忙发布，破坏已有内容呢？我试图说服苹果延迟发布对 OffscreenCanvas 的支持，但得到的答复模棱两可，大概他们还是会按照原计划发布。

在我看来，苹果是不想更改时间表。我们面临着灾难，苹果只需要延迟 Safari 16.4 中许多新功能之一，就可以避免这次灾难。最后，他们添加了一个特殊的选项来检测我们的引擎并禁用 OffscreenCanvas。这确实可以让我们避免兼容性灾难。但对于犯了相同错误的其他人来说就不是好消息了，这个特殊选项可能救不了你们。

最近这几周，我的压力特别大，我感到寝食难安，就因为这些不确定性：我们究竟是面临灾难，还是说一切都会平安无事？我不知道究竟会怎样，我也不知道到什么时候我们才能搞清楚。连续数周，每一天我都惴惴不安，不知道今天将是风平浪静，还是会发生灾难，也无力判断哪天会发生灾难。实际上，Safari 以前的版本也引发过类似的问题，只不过通常都没有这么糟糕。

我们都是人类，遇到这样的事情，就会造成损失。我要指出的是，我们公司已经成立十多年了，如今是拥有 250,000 月活跃用户的成功企业，我在休假时间也遇到过灾难、争议、愤怒的客户、突然发生意外的服务器故障等等。这些问题都很艰难，但你会以专业人士的身份坚持下去。

然而，此次应对 Safari 的新版本是我最糟糕、压力最大的经历之一。最令人沮丧的是，这些灾难本可以轻松避免，只要苹果做出一些简单的改变，就可以缓解我们的大部分压力，然而多年来他们坚决不做出任何此类改变。

我的这些意见不针对任何特定的苹果员工，这种压力不是某个人单独造成的，实际上我注意到苹果许多员工都有出色的表现，他们不乏聪明和勤奋的人。问题在于，苹果管理这些版本的政策。缺乏透明度会导致很大的不确定性，我认为正是这些政策导致我以及其他 Web 开发人员承受如此巨大的压力。

以前，Safari 的新版本发行没有这次如此糟糕，但也发生过类似的事情，并造成了很大的压力，导致我们的正常工作暂停。以下是过往我们遇到 Safari 问题的简要总结。

▶ iOS 11.2.2 破坏了 WebAssembly，导致维基百科的部分内容、我们所有已发布内容以及其他发布的内容遭到破坏。如果苹果禁用 WebAssembly，本来大多数问题都可以避免，但他们没有这么做，所以我们都受到了影响，直到几个月后 iOS 11.3 发布。在此期间内，苹果没有提供任何有意义的帮助或支持，我们只得到了一位乐于助人的维基百科工程师的支持，他分享了一些解决方法。

▶ Safari 11.1 破坏了我们的 MessageChannels，导致我们长达数年一直坚持使用应急方法。

▶ Safari 14 发布了一个有问题的 replaceChildren() 方法，导致我们的产品出现故障。

▶ Safari 14 破坏了 localStorage，间接导致 IndexedDB 出问题。

▶ 即使已解决的问题也有可能制造压力和不确定性。Safari 15 中的音频问题导致我们的音频播放出问题，而这个问题在 Safari 15 发布之前就已修复，但苹果从不会提前证实，所以我不得不自己检查。

▶ Safari 15.0～15.4 中的 WebGL 错误导致我们的某些页面一片空白，最终这个问题在 Safari 15.5 中得到了修复，但我们从未得到通知，只能手动检查 Safari 的每个版本。

▶ 多年来，我们一直想要一种可以在所有浏览器中播放的单一开放音频文件格式。WebM Opus几乎实现了：所有浏览器都支持，包括 macOS 上的 Safari，但偏偏 iOS 和 iPadOS 不支持。这是我们能够在所有浏览器中使用该格式的唯一障碍，移除这个障碍就可以大幅降低网络音频支持的复杂性。然而，目前还不清楚苹果是否有在尝试解决这个问题，我提交该问题已经一年多了，但他们并没有明确的表示。

▶ Safari 16 中在某些情况下会破坏我们的音频播放。对此，苹果并没有做出任何有意义的回应，这个问题我大约是在 6 个月前提交的。

▶ 有些提交的问题会无故消失。这个问题（/d/file/gt/2023-09/hnpeqwgynom.html Firefox 提交地类似问题（/d/file/gt/2023-09/asepssz5h2h.html Safari 有如此严重的问题，其他浏览器制造商很少有任何此类问题，而且他们完全透明，我们可以制定出相应的计划。

如何解决这个问题？简单的答案是：苹果像其他浏览器制造商学习。其他浏览器制造商从未给我们带来如此严重的问题，很大一部分原因是他们为像我们这样的 Web 开发人员提供了优越的开发流程，其中包括：

▶ 透明度：告诉开发人员将在哪些版本中发布错误修复，而且也会公开发布时间表——仅此一项就可以消除大量的不确定性。

▶ Safari 的更新不依赖于操作系统：Safari 是业界最后一款与其操作系统绑定的浏览器，这是更新 Safari 的一个巨大障碍。即使是一个很小但很重要的更新也需要等到下一次系统更新，这无疑增加了解决严重问题所需的时间，通常长达几个月。如果 Safari 团队能够自行控制发布周期，并认真管理，我相信许多问题的影响都会得到极大限制。

▶ 更多预发布测试选项：就像 Chrome Canary 和 Firefox Nightly 一样，每天更新，并独立于操作系统，这将有助于快速迭代问题，并验证它们是否已修复。iOS 和 iPadOS 上也应该提供这样的预发布测试和 STP，目前测试 Safari 预发布版本的唯一方法是使用整个测试版系统更新，这样既缓慢又不方便。

▶ 沟通：错误时有发生，如果 Safari 的某些问题导致我们的系统中断，苹果应该告诉每个人发生了什么，他们正在做什么，什么时候可以解决，以及开发人员在此期间可以做什么。但通常苹果的反应就是沉默，给人一种漠不关心的样子。我相信苹果的员工很在乎，但从外人来看，苹果的沟通确实很糟糕。

根据我的经验，所有其他浏览器制造商在上述方面都有良好的表现，只有苹果很糟糕。Safari 发布新功能当然受欢迎，但似乎苹果只专注于 Safari 16.4，并没有采取任何措施来解决这些问题。

最终，我们的产品还是正常工作了。你可能会问：所以我在抱怨什么？

看似我在小题大做，但实际上仅仅是为了让 Safari 的常规发布版本正常运行，就让我们心力憔悴。更重要的是，下一个版本，下下一个版本，我们还会再经历一次次这样的折磨，迟早我们会有所疏漏，再次面临灾难……每每想到这里，我就感觉五脏六腑都在翻滚。

我希望自己能够喜欢上 Safari，因为它确实包含了很棒的技术，最新版本也提供了许多令我们感到兴奋的功能。另外，很显然苹果不乏才华横溢的员工，他们能够迅速查明技术问题。

可悲的是，我非常害怕 Safari 发布新版本。苹果明明可以做得更好，但这么多年每次发布都会引发严重的问题。在许多情况下，苹果只需采取一些小动作就可以在很大程度上解决困难，但他们坚持同样的流程，从未表现出任何改变的兴趣。每次像我这样的开发人员处理由此引发的问题，都犹如从地狱里走一遍：

为我们的正常工作带来不必要的干扰，浪费时间寻找苹果明明知道却不肯告诉我们的真相，时刻处在不知道什么时候会发生什么的惊恐中，面对迫在眉睫的灾难带来的压力和不确定性而无从下手——在我看来，这都是他们的疏忽造成的。

我非常希望苹果能够改变，希望 Safari 能成为出色的浏览器，希望开发出能在 Safari 中正常运行的产品，希望 Safari 能成为健康网络中强有力的浏览器竞争对手……坦白讲，我希望的就是苹果能为我的心理健康做出改变。

如果苹果坚持不改，我认为唯一的选择就是告诉人们改用 Chrome 或 Firefox，并要求监管机构强制他们改变。尽管最近监管机构有所动作，但这个新版本表明 Safari 的问题越来越严重，而苹果似乎对取消监管更感兴趣。如果我们都投入 Chromium ，这将不利于网络的发展，自身也会有问题。但就目前的情况而言，我不得不说，我不希望再次处理 Safari 的新版本问题。