查看详情

WebVR 可用性探测

Chrome 在 72 或者之后的版本开始支持 WebVR 的 API (75+ 移至 WebXR 的草案之中)。包括所有集成 Blink 内核的浏览器都会默认支持这个 API。但是实际上,我们做 VR 开发体验的时候还是希望能在合适的头显设备(HMDs)进行功能展示。 我们看下 caniuse 对 WebVR 的支持情况 其中显示: 这个意思是目前依旧需要手动开启功能,对于 Oculus 或者 HTC vivi 的头显,集成 Chrome 内核的浏览器都对该功能表示支持。 由于国内厂商集成内核版本的问题导致一些移动端浏览器默认开启了对 webVR 的支持,但是实际效果并不是理想。 我们常规检测是 if (typeof navigator.getVRDisplays === 'function') { navigator.getVRDisplays().then(displays => { if (displays.length) { // support 详情 »

查看详情

使用原生 Web Share API 进行内容分享

Chrome 75 开始支持 Web Share API - Level 2, 这也就意味着你可以通过 JS 分享 文件,链接或者文本到其他的 App 了。 其实这个需求很早很早,我们的 PM 就开始提了,关于实现,目前比较成熟的是通过 JS Bridge,然后利用 APP 的能力唤起分享面板。但是我们还是无法通过 Chrome 或者 Safari 实现页面内通过 JS 执行唤起分享面板。详情可以见《H5 互动营销》。 canShare() 以及 share() 当然目前这个还是一个处在实验性的 API ,我们还是需要去做一些兼容性判断。分享文件,我们还需要确认这些文件是否处于可分享的状态。可以尝试 Chrome 团队给的代码 const shareData = { files: filesArray }; if (navigator.canShare & 详情 »

查看详情

解决 Synchronous XHR in page dismissal 的问题

如果你更新了最新的 Chrome (大约 >= 73 的部分版本),发现有些日志没有发送的时候,需要引起注意了。你需要关注是否有一些异常或者警告产生类似 Uncaught DOMException: Failed to execute 'send' on 'XMLHttpRequest': Failed to load 'https://xxxx/': Synchronous XHR in page dismissal. 目前还并不能明确具体会在什么版本采用这个策略,当前有可能只是部分版本限制了 至今, Synchronous XHR 都是不被推荐使用的,但是我们还是会在一些特殊场景中使用到,比如页面 unload 或者 beforeunload 用于表示用户离开页面的数据发送。不过不好的消息便是,Chrome 正计划限制这类似的请求。 于是乎我们看到了很多人在最近几天发布了这个问题 传送门 https://stackoverflow.com/questions/55676319/ajax-synchronous-request-failing-in-chrome 目前比较好的解决方式只有 navigator.sendBeacon(), 它不会阻塞 main 详情 »

查看详情

Is Service Worker in Sandbox

其实这个话题,对很多人而言,如果之前没有细致了解过 Chrome 设计架构,还真不好说出答案,不过好在 Chrome 官方写了四篇文章,详细的阐释 Chrome 适合实现多进程,以及其具体作用的。 Chrome 的多进程设计 输入 URL 浏览器做了什么 Renderer process 如何渲染页面 Chrome 与页面的事件交互 那么 Service Worker 是否运行在沙箱中呢? 我们先看下 Chrome 的多进程架构。 图1 浏览器多进程模型 如图所示,Chrome 包含多个进程,而其中 Browser Process 主要负责浏览器的 UI(比如上面那些插件图标显示,每个tab 的控制,输入框的交互事件等等...),Renderer Process 顾名思义,则是最为核心,我们每个页面渲染的进程,即我们每打开一个 Tab 访问某个页面,就会产生一个 Renderer Process。而 详情 »