ie88 最近的时间轴更新 ie88 最近的时间轴更新 |
ie88V2EX 第 222302 号会员，加入于 2017-03-21 23:49:42 +08:00 |
| 请问各位工作中做的事有成就感吗？ 程序员 • ie88 • 79 天前 • 最后回复来自 FFFFourwood | 38 |
| 朝九晚九大小周，半年了，身心俱疲。 程序员 • ie88 • 2017-08-04 02:53:12 AM • 最后回复来自 PythonAnswer | 104 |
ie88 最近回复了
86 天前 回复了 ie88 创建的主题 › 程序员 › 请问各位工作中做的事有成就感吗？ |
@07ly 前端写页面或者后端 CRUD 有很多重复性工作，确实不如解出一道算法题来的成就感大
86 天前 回复了 ie88 创建的主题 › 程序员 › 请问各位工作中做的事有成就感吗？ |
@erhsilence 前端还是后端呀
161 天前 回复了 xiangyuecn 创建的主题 › 程序员 › 稳定复现，看我几行代码搞崩 Chrome |
@gadfly3173 我是觉得咱们这样的技术论坛就是应该有人去发现问题，讨论问题，定位问题，甚至解决问题。希望这个帖子能够吸引一些 V8 引擎开发团队的成员，来讲解一下目前这个问题故意不 catch 这样的 exception 来约束开发者，还是说确实属于 bug 需要修复，或者 browser policy 的制定团队有人解释一下这个 block 操作是不是包含页面崩溃这种做法。
161 天前 回复了 xiangyuecn 创建的主题 › 程序员 › 稳定复现，看我几行代码搞崩 Chrome |
@gadfly3173 不是，页面崩溃是在开发者开发测试上线环节都会遇到的问题，开发者遇到这样严重的 bug 怎么会把这样的代码放到生产环境去跑，用户层面无法感知这样的页面崩溃，这个过程是在开发测试上线环节已经约束了开发者，是不影响用户的，因为你正经做开发怎么会带着这样的 bug 上线。你想实现自动播放，直接 mute 就可以呀，unmute 就是不让你的代码成功跑起来，应该没问题吧
161 天前 回复了 xiangyuecn 创建的主题 › 程序员 › 稳定复现，看我几行代码搞崩 Chrome |
而且就 block 这个做法来讲，开发者在开发测试上线各个环节都会遇到崩溃的情况，能够及时修复这个问题，基本没有机会让用户操作导致页面崩溃的情况发生，这样既保护了用户又约束了开发者，这种做法不合适嘛？
161 天前 回复了 xiangyuecn 创建的主题 › 程序员 › 稳定复现，看我几行代码搞崩 Chrome |
161 天前 回复了 xiangyuecn 创建的主题 › 程序员 › 稳定复现，看我几行代码搞崩 Chrome |
"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 没提到，我个人认为就是直接让页面崩溃，他们找不到比这更合适的做法了
161 天前 回复了 xiangyuecn 创建的主题 › 程序员 › 稳定复现，看我几行代码搞崩 Chrome |
@ie88 更正一下，是 roughly half 而不是 all
161 天前 回复了 xiangyuecn 创建的主题 › 程序员 › 稳定复现，看我几行代码搞崩 Chrome |
effectively blocking roughly half of unwanted media autoplays in Chrome ，是 half 而不是 all ，不也正好解释大家半天测试的时候，有的时候出现崩溃，有的时候没崩溃的情况吗
161 天前 回复了 xiangyuecn 创建的主题 › 程序员 › 稳定复现，看我几行代码搞崩 Chrome |
@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 不是吗？
我刚看了下 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 不是吗？
Select Language