self.skipWaiting() 在 Service Worker 中不起作用 [英] self.skipWaiting() not working in Service Worker

查看:69
本文介绍了self.skipWaiting() 在 Service Worker 中不起作用的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我有一个服务人员.这是安装事件:

I have a service worker. Here's the install event:

self.addEventListener('install', function (event) {
    console.log('Installing Service Worker ...', event);

    return self.skipWaiting()
    .then(() => caches.open(CACHE_STATIC_NAME))
    .then(function (cache) {
        return cache.addAll([
            './file1.html',
            './file2.html'
        ])
    })
});

由于某种原因,当我编辑 service worker 代码并更新 service worker 文件 URL 中的查询参数时,它安装但未激活(根据 Chrome DevTools)—即使我已经调用了 self.skipWaiting().

For some reason, when I edit the service worker code and update the query parameter in the service worker file URL, it installs but does not activate (according to Chrome DevTools) — even though I've called self.skipWaiting().

奇怪的是,如果我进入控制台,进入 Service Worker 的范围并自己输入 self.skipWaiting(),它会立即激活.

Oddly if I go into the console, go to the scope of the service worker and type self.skipWaiting() myself, it activates immediately.

几个小时以来,我一直试图弄清楚发生了什么,但我完全被难住了.有什么我在这里遗漏的吗?

I've been trying to work out what's going on for many hours now, and I'm completely stumped. Is there something I'm missing here?

推荐答案

旧的 SW 在它仍在运行任务时可能不会停止 - 例如,如果它有一个长时间运行的 fetch 请求(例如服务器发送的事件/事件源,或 fetch流;虽然我不认为 websockets 会导致这种情况,因为我认为 SW 会忽略它们).

The old SW might not stop while it's still running tasks - for example if it had a long running fetch request (e.g server sent events / event source, or fetch streams; although I don't think websockets can cause this as SW will ignore them I think).

不过,我发现浏览器之间的行为有所不同.Chrome 似乎在现有任务运行时等待(因此 skipWaiting 将失败...),但 Safari 似乎终止了任务并激活了新的软件.

I find the behaviour to be different between browers however. Chrome seems to wait while the existing task is running (so skipWaiting will fail...), but Safari seems to kill the task and activate the new SW.

测试这是否导致您的问题的一个好方法是在您请求 skipWaiting(以终止网络连接)之后立即终止您的服务器.(只是在开发工具中点击离线"似乎并没有杀死所有正在运行的连接,例如 EventSources 保持运行.)

A good way to test if this is causing your issue would be to kill your server just after you request the skipWaiting (to kill the network connections). (Just clicking "Offline" in Dev Tools doesn't seem to kill all running connections, for example EventSources stay running.)

您可以让软件忽略某些路由(如下),或者您可以尝试强制请求终止(可能使用 AbortController).

You can have the SW ignore certain routes (below), or you could try and force the requests to terminate (maybe using AbortController).

self.addEventListener('fetch', function(event) {
  const { method, url } = event.request;
  if(event.request.method !== "GET") return false;
  if(url === "https://example.com/poll") return false;

  event.respondWith(
    caches.match(match).then(function(response) {
      return response || fetch(event.request);
    })
  );
});

skipWaiting 的过程在这个规范中:

The process for skipWaiting is in this spec:

https://w3c.github.io/ServiceWorker/#try-activate-算法

但我不太清楚浏览器是否应该在激活新软件之前等待任务或终止它们(或将它们转移到新软件?);如前所述,目前浏览器之间的工作方式似乎有所不同......

But I don't find it very clear about whether the browser should wait for tasks or terminate them (or transfer them to the new SW?), before activating the new SW; and as mentioned, it seems to work differently between browsers at the moment...

这篇关于self.skipWaiting() 在 Service Worker 中不起作用的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆