13:37
<devsnek>
if a service worker was written stupidly to never update, is there a way to kill it without telling everyone who ever opened the website to hard refresh
13:38
<devsnek>
I was reading some old gh threads mentioning this but it didn't look like anything concrete ever came about
14:26
<Jake Archibald>
if a service worker was written stupidly to never update, is there a way to kill it without telling everyone who ever opened the website to hard refresh
I don't think it's possible to write a service worker that never updates
14:26
<Jake Archibald>
Even if you far-future cache it, that's capped to one day
14:26
<devsnek>
it has been a couple weeks now and my phone, for example, where I can't hit hard refresh, still shows the old site
14:27
<Jake Archibald>
Are you sure it isn't trying to update, and failing?
14:27
<Jake Archibald>
rather than not trying to update
14:27
<devsnek>
🤷‍♂️
14:27
<devsnek>
what does update here imply, just trying to re-fetch the worker url?
14:28
<foolip>
Jake Archibald: do you still need me to say something on that bug?
14:28
<Jake Archibald>
devsnek: https://developers.google.com/web/fundamentals/primers/service-workers/lifecycle
14:29
<Jake Archibald>
foolip: If you feel it's something that can & should be fixed, yeah. The triage guy still seems to think it's behaving correctly
14:30
<Jake Archibald>
(kinda a bad experience, if I didn't work for the company I'd have given up by now)
14:31
<Jake Archibald>
Doesn't need to be a lengthy reply, just a nod that it shouldn't be closed "wontfix", which has happened twice already
14:31
<foolip>
Jake Archibald: That’s Aleks of TablesNG and microtask timing fame, I think you’d get along well in real life :)
14:32
<Jake Archibald>
foolip: eh maybe. I just feel the reduced cases I created were ignored
14:32
<devsnek>
jake is this saying if the worker url 404s, it will keep the old one?
14:33
<Jake Archibald>
devsnek: correct
14:34
<Jake Archibald>
devsnek: lots of history there if you want to get into it https://github.com/w3c/ServiceWorker/issues/204
14:35
<devsnek>
thx jake
14:36
<Jake Archibald>
foolip: oh, wait, I do know the guy, and yeah we got on. Guess we're just having an off day communication-wise.
14:40
<foolip>
Jake Archibald: commented with typos
14:40
<Jake Archibald>
best kind of comment
14:40
<foolip>
Or what’s the word when you omit some words?
14:41
<Jake Archibald>
Whatever it is, it's what I do in like half of my tweets
14:41
<Jake Archibald>
Thanks for adding the comment!
14:42
<Jake Archibald>
I'll create some spec issues for this and file bugs in other browsers on Monday
14:42
<Jake Archibald>
(even if it's just to match the language currently there for mutation observers)
14:43
<Jake Archibald>
Kinda surprising that all browsers seem to have the same pattern where listeners and MutationObserver don't leak, whereas IntersectionObserver and ResizeObserver leak. I guess it's because layout is seen as being outside the element.
17:05
<aja>
devsnek, tried having server send a Clear-Site-Data header?
17:06
<devsnek>
fixing the 404 worked
17:06
<devsnek>
https://github.com/discordjs/website/blob/main/public/service-worker.js
22:56
<bakkot>
what happened to the CSS on the webidl spec?
22:56
<bakkot>
oh, https://www.w3.org/ is giving a 503, I see
22:59
<sideshowbarker>
yeah it went down about 11 hours, and stayed down for more than 2 hours before coming back
22:59
<sideshowbarker>
so it’s likely to be down again for a while
23:01
<sideshowbarker>
for the record here, the cause it’s an internal W3C problem but instead a problem caused by the hosting service that W3C uses
23:01
<bakkot>
also, if anyone can review PRs to webidl, it would be good to get a review on https://github.com/heycam/webidl/pull/914, since there's currently a mismatch between the two specs: ecma262's CreateBuiltinFunction now takes more required arguments than webidl provides it, and this PR fixes that