Windows 8.1下Chrome/Edge调用Web Share API返回延迟异常是怎么回事？

基础调用代码 #

btn.addEventListener('click', () => {
  navigator.share(shareData)
    .then(() =>
      console.log('Web Share 调用成功')
    )
    .catch((e) =>
      console.error('调用错误: ' + e);
    )
});

异常表现 #

按设计navigator.share会返回Promise，用户拒绝授权或系统拦截请求时应当快速触发失败回调。但实际测试中存在以下问题：

• 抛出的固定错误信息为 Error: AbortError: Share canceled
• 错误触发前无任何分享相关UI弹出，用户没有执行主动取消操作，属于系统直接拦截调用
• 从点击触发到收到错误回调的延迟超过20秒，断开互联网连接也不会改变该现象
• 复现环境为Windows 8.1 Pro，Chrome 89.0.4389.128、Chrome 90.0.4430.93、Edge 89.0.774.54 64位正式版均可稳定复现

根因说明 #

Windows 8.1 无内置系统级分享面板的原生支持，桌面端Chromium内核浏览器对该版本系统的Web Share API实现存在兼容性缺陷：遇到不满足接口运行条件的系统环境时，不会快速抛出能力不支持错误，而是等待系统层超时回调，才会返回拦截后的AbortError，这就是20秒以上延迟的来源。

落地解决方法 #

• 前置校验替代被动等待
  不要依赖原生Promise的返回结果判断接口可用性，调用navigator.share前先完成三层校验：

1. 首先判断navigator.share是否存在于当前window对象上，不存在直接走降级逻辑
2. 针对Windows 8.1这类已知存在兼容问题的环境，提前通过UA特征识别跳过原生分享调用
3. 增加超时兜底机制：给navigator.share的Promise增加5秒竞速超时，只要超时就直接触发降级流程，不等原生接口的延迟回调

• 降级逻辑触发时机优化
  摒弃“等待错误回调才触发降级”的被动逻辑，替换为点击分享按钮后优先弹出内置的网页分享面板，同时在后台调用Web Share API；如果接口快速返回成功，就关闭内置面板走原生分享流程，如果接口超时或返回错误，就直接保留内置分享面板，全程不阻塞用户操作
• 对于捕获到的AbortError，不需要设计重试逻辑，该错误本身就是系统直接拦截的固定反馈，没有重试价值

内容的提问来源于stack exchange，提问作者kubicle