稳定复现，看我几行代码搞崩 Chrome

[xiangyuecn]

搞崩 chrome 测试页面： https://xiangyuecn.gitee.io/recorder/assets/ztest_chrome_bug_AudioWorkletNode.html （打开后可能需要右键刷新一下页面）

过程分析记录： https://www.cnblogs.com/xiangyuecn/p/15988061.html

最新的 chrome 97 打开测试页面测试后每次都会崩溃，最开始发现的 chrome80 也会崩溃（不过测试页面反而不会崩了），古董版本 66 70 不会崩溃，更老的不支持 AudioWorklet 不用测试

这个崩溃现象也就是在特定时机才会出现，FireFox 测试的完全没有这个问题

[×]提交 bug

[√]v2ex 发帖

测试页面截图：

崩溃截图：

[gadfly3173]

@ie88 各大视频网站还有一堆默认自动播放视频的操作呢，浏览器也不是直接允许的，也没看有哪家浏览器针对这种行为做提示啊？浏览器只需要做规范里提到的内容就可以了，不应该画蛇添足自以为是

[ie88]

@gadfly3173 你说的这些目前是这样的，可是如果 AudioContext 这个 API 没经过用户操作就能进行音频播放的话，是不是很容易出现类似网页被挂马这种情况，自动播放一些不和谐的音频，可能让审查机构误认为是网站开发人员故意操作的。

[ie88]

@gadfly3173 你说的自动播放视频通常视频流是被加密了的，应该不会被恶意篡改。而 AudioContext 这个 API 播放音频流应该没有做到加密处理，应该被恶意篡改的风险很高吧

[gadfly3173]

@ie88 。。。所以浏览器只要阻止操作就可以了。。你要区分有关用户的安全问题和流氓行为。安全问题浏览器应当阻止并提示，流氓行为最多阻止就好了。什么网站挂马之类的不在浏览器应该考虑的范围。包括还有 xss 之类的操作，防范这些无法被机器判断的安全问题应该是网站自身做好的，而不是让浏览器解决。

[ie88]

@gadfly3173 哦，我大致明白了，多谢指点。

[q1angch0u]

幸好 iOS 的 chrome 用 webkit [狗头]

[iajr]

Google Chrome
版本 99.0.4844.51 （正式版本） (x86_64)
macOS 12.2 （ Intel ）
成功复现

[iajr]

又试了一下，发现并不是每次都会复现，有一定概率崩溃

[ie88]

@gadfly3173 https://developer.chrome.com/blog/autoplay/#webaudio
我刚看了下 Autoplay policy in Chrome ，有以下描述

The Autoplay Policy launched in Chrome 66 for audio and video elements and is effectively blocking roughly half of unwanted media autoplays in Chrome. For the Web Audio API, the autoplay policy launched in Chrome 71. This affects web games, some WebRTC applications, and other web pages using audio features. More details can be found in the Web Audio API section below.

As you may have noticed, web browsers are moving towards stricter autoplay policies in order to improve the user experience, minimize incentives to install ad blockers, and reduce data consumption on expensive and/or constrained networks. These changes are intended to give greater control of playback to users and to benefit publishers with legitimate use cases.

Chrome's autoplay policies are simple:

Muted autoplay is always allowed.
Autoplay with sound is allowed if:
The user has interacted with the domain (click, tap, etc.).
On desktop, the user's Media Engagement Index threshold has been crossed, meaning the user has previously played video with sound.
The user has added the site to their home screen on mobile or installed the PWA on desktop.
Top frames can delegate autoplay permission to their iframes to allow autoplay with sound.

我觉得这个 policy 已经说得很明确了，所以页面直接崩溃（ effectively blocking roughly half of unwanted media autoplays in Chrome ）是 Chrome 现在正在用的做法，不属于 bug 不是吗？

[ie88]

effectively blocking roughly half of unwanted media autoplays in Chrome ，是 half 而不是 all ，不也正好解释大家半天测试的时候，有的时候出现崩溃，有的时候没崩溃的情况吗

[ie88]

@ie88 更正一下，是 roughly half 而不是 all

[Routeros]

版本 99.0.4844.51 （正式版本） （ 64 位） 复现

[ie88]

"web browsers are moving towards stricter autoplay policies in order to improve the user experience"，就提升用户体验来讲，chrome 团队认为 "block unwanted media autoplays" 要比 allow unmuted media autoplays 好，所以他们进行了 block 处理，如何实现 block ，这个 policy 没提到，我个人认为就是直接让页面崩溃，他们找不到比这更合适的做法了

[ie88]

@xiangyuecn @Huelse @gadfly3173 请各位看看这个 policy ，是不是我说的这个意思

[ie88]

而且就 block 这个做法来讲，开发者在开发测试上线各个环节都会遇到崩溃的情况，能够及时修复这个问题，基本没有机会让用户操作导致页面崩溃的情况发生，这样既保护了用户又约束了开发者，这种做法不合适嘛？

[Mac]

@shakoon #15 感人啊，到现在还有百分的用户坚持着。我春节期间彻底弃用换 EDGE 了，因为 NAS 的菜单已经不兼容了。

[gadfly3173]

@ie88 。。。你的理解有大问题。。。阻止自动播放真的只是字面意义上的不能自动播放，也就是视频暂停 /音频暂停之类的。。。页面崩溃可不是什么正确的阻止播放的做法。。。你要站在一般用户的立场上来思考。。。不如你用隐身模式打开个视频网站试试。。。

[ie88]

@gadfly3173 不是，页面崩溃是在开发者开发测试上线环节都会遇到的问题，开发者遇到这样严重的 bug 怎么会把这样的代码放到生产环境去跑，用户层面无法感知这样的页面崩溃，这个过程是在开发测试上线环节已经约束了开发者，是不影响用户的，因为你正经做开发怎么会带着这样的 bug 上线。你想实现自动播放，直接 mute 就可以呀，unmute 就是不让你的代码成功跑起来，应该没问题吧

[ie88]

@gadfly3173 我是觉得咱们这样的技术论坛就是应该有人去发现问题，讨论问题，定位问题，甚至解决问题。希望这个帖子能够吸引一些 V8 引擎开发团队的成员，来讲解一下目前这个问题故意不 catch 这样的 exception 来约束开发者，还是说确实属于 bug 需要修复，或者 browser policy 的制定团队有人解释一下这个 block 操作是不是包含页面崩溃这种做法。

[SimonOne]

Vivaldi 5.1.2567.57 (Stable channel) (x86_64) 复现

[kaedea]

Android Chrome 成功复现

[cyp0633]

Chromium 101.0.4928.0 刷新两次后崩溃

[maskerTUI]

Chromium 86 崩溃

[Wanerlove]

Chrome 101.0.4935.0 稳定复现

[sarvatathagata]

Chrome 99.0.4844.51 Ubuntu 20.04 经过刷新与彻底刷新，重开浏览器等尝试，没有任何崩溃

[luzemin]

Version 99.0.4844.51 (Official Build) (64-bit)

多刷几下崩溃

[skiy]

About

Microsoft Edge
Version 99.0.1150.30 (Official build) beta (64-bit)
This browser is made possible by the Chromium open source project and other open source software.

Microsoft Edge

不打开控制台，浏览器没崩，页面也没崩。
打开控制台，浏览器没崩，页面崩。

[abc612008]

@ie88

这当然是 bug ，浏览器在任何情况下都不应该崩溃。这里的正常行为是发出下面这样一个 warning ，然后 Audio 没有被自动播放。

The AudioContext was not allowed to start. It must be resumed (or created) after a user gesture on the page. https://developer.chrome.com/blog/autoplay/#webaudio

如果你打开楼主那个网页的话也能看到这么一个 warning 。如果你再仔细看的话，这里崩溃的时刻已经是在 user gesture 之后了（用户点击网页后才执行的代码）。所以崩溃很可能和 autoplay 关系不大，或者最多是这个 autoplay policy 的 unintended 副作用(bug)。

其次，崩溃的错误代码是 STATUS_ACCESS_VIOLATION. Access violation 通常指代的是访问一块没有对应权限的内存。显然这和你所说的 autoplay policy 没有什么关系。

如果你还坚持这是个正常行为的话，那怎么解释这个网页有时候崩有时候不崩呢。

[kilasuelika]

安卓 101 版本，第一次打开时崩了，后来就没有了

[her999]

版本 99.0.4844.51 （正式版本） （ 64 位） for linux 复现成功。点一下，稍等一会，奔溃。

[maomaochong199]

@xtinput 你怎么在用 arm 架构，是什么机子啊

[baysonfox]

Microsoft Edge 99.0.1150.39 (x86_64) 复现不稳定，10 次测试内有 3~5 次失败, 其余成功复现.

[l4ever]

360 极速 x
内核 95, 扛住了.

[shakoon]

@Mac #116 我发觉每一个被我长期使用的浏览器最后都会倒闭……十几年前 maxthon2 我用了好多年，被收购后改得惨不忍睹。后来 chrome 崛起后用的枫树浏览器也是莫名其妙的倒闭了，一直用到大约 18 年好多网页都显示不正常了才不得不换。现在百分一年多没更新，不知是不是也凉了。目前倒是没遇到什么网站不兼容，但愿能多撑一段时间吧。
话说这家小公司国内外用户还是不少的，真要是经济困难开放一个捐助通道我觉得还是能募集到一些资金的。我觉得更大的可能性是因为动到了被某大厂的蛋糕，被悄悄收购了然后安乐死

[xtinput]

@maomaochong199 #133 21 款 16 寸 M1Max

[yxzblue]

Chrome 98.0.4758.102 没崩

[heliang]

chrome 版本 99.0.4844.51 （正式版本） (arm64)
崩溃

[yveJohn]

Microsoft Edge
版本 98.0.1108.43 (官方内部版本) (64 位)
未复现

[yxisenx]

崩了， 版本 99.0.4844.51 （正式版本） （ 64 位）

[acess]

chrome 的 audioworklet 好像还有内存泄漏 bug 来着，各种 disconnect 、close context 都删不掉，所以如果反复创建就可能爆内存。

[acess]

话说我也觉得，点击一下页面就播放音频，虽然不是完全没拦截，但还是不如弹个窗确认好。

[xuyl]

借楼，win7 chrome v99.0.4844.51 ，出现标签页混乱卡顿问题，有人遇到吗？

[24bit]

99.0.4844.51 复现

[Atsushi]

Microsoft Edge
版本 99.0.1150.36 (正式版本) (64 位)
Microsoft Edge
版本 99.0.1150.39 (正式版本) (64 位)
都崩了

[GeruzoniAnsasu]

@ie88 一句话阻止抬杠：
access violation 是 segment fault

你写了一个读取空指针的代码并视其为「用户保护措施」

[Lemeng]

ff 正常

[MonkeyJon]

谢谢你，陌生人

[aurtech]

坐标深圳，求一枚 Golang/Python 大佬！！欢迎砸简历 V：Ifboredgunquxuexi.

[Kaiv2]

Microsoft Edge
版本 99.0.1150.36 (正式版本) (arm64)
时好时坏

[alan0liang]

Chromium 版本 98.0.4758.102 （正式版本） Arch Linux （ 64 位）
只有第一次崩了，后面再刷新就没事了

[ablu]

1/6 、2/6 、3/6 正常 4/6 、5/6 、6/6 崩溃
Google Chrome
版本 99.0.4844.51 （正式版本） (x86_64)

[nkcfc]

Linux 下，Chrome beta 版本 99.0.4844.27 （正式版本） beta （ 64 位）
刷新后复现。

[azraeljack]

Edge 98.0.1108.56 试了几次没有崩

[neiltroyer849]

Chrome 103 macOS 12.5 Arm64 ，稳定复现，次次都崩

[binux]

过来 ping 一下 LZ ，看一下 CVE-2023-1222 如果当初
[√]提交 bug
可能$7000 就到手了

[xiangyuecn]

@binux #155 😂牛逼 错过一个亿

https://bugs.chromium.org/p/chromium/issues/detail?id=1403515

Permission denied. 100w 刀也不提交

[binux]

@xiangyuecn 安全 bug 是不公开的，但是看 cve 描述是一致的

[xiangyuecn]

@binux 原来如此，看不到也是心痒痒😁