WHATWG on 2025-05-15

06:08	<Domenic>	smaug: I think we do it the same as desktop? If the iframe is focused, its close watchers are targeted, otherwise the top-level's close watchers are targeted?
08:02	<annevk>	Is there someone in the WHATNOT meeting who can let other people in?
09:35	<zcorpan>	https://developer.chrome.com/blog/smooshgate/ is great and should be required reading
15:22	<akaster>	Is it expected to be confused by the `shared worker manager` steps in https://html.spec.whatwg.org/multipage/workers.html#dom-sharedworker ? We start execution in the Agent corresponding to `outside settings`. Then we're expected to iterate over a list of SharedWorkerGlobalScope objects, which might exist in different agents or agent clusters from the one we're in. I can understand that this should be some abstract 'ask the user agent global data about this' operation. Then in step 11.5 we're supposed to, in the realm/agent of the caller of the SharedWorker constructor, create a message port to entangle with the existing shared worker object. But like mentioned above, the shared worker global scope might not even exist in the same agent or agent cluster. So we're supposed to hand-wave some IPC to connect a new owner and IPC message port connection? The run a worker steps at least take the time to `obtaining a dedicated/shared worker agent` and be explicit about who is calling what from where 😅
16:46	<annevk>	akaster: there might be an issue around refactoring that better. It should prolly use parallel queue to ensure everyone is looking at the same user agent managed list of shared workers.
16:47	<annevk>	akaster: I think I looked at doing that when we integrated with agent clusters, but there was something hairy about it.
17:23	<akaster>	It does mention that there's a parallel queue, but I don't know if I understand the implications of that related to cross-agent synchronization
18:02	<annevk>	akaster: mainly that each algorithm run on it is done sequentially, but the order in which the algorithms are queued is a race I think. But the current setup is very confused as it just grabs random globals while being in parallel. That's a no-no.
18:04	<akaster>	Gotcha. I did think that that the part where the algorithm grabs at several different globals at a time was the most confusing. I suppose the automated checks dontcallmedom was running that look for that sort of thing "in parallel" don't catch when things are hidden behind a named parallel queue
18:06	<annevk>	I actually can't find a canonical issue that tracks how broken this is.
18:07	<annevk>	Want to file an issue? This kind of thing is definitely worth fixing, though getting it prioritized might be tricky. But perhaps we can impose it on the next person doing something non-trivial with workers.
20:36	<akaster>	Sure, I'll write it up
23:56	<akaster>	this comment seems to hint that it was known at some point that there's something fishy going on here. https://github.com/whatwg/html/issues/5362#issuecomment-600599684
23:58	<akaster>	here as well, in item 3. https://github.com/whatwg/html/issues/5323#issuecomment-594361179
23:59	<akaster>	I guess I can make a new issue and reference those two places to specifically point out the wishy-washy global scope accesses in parallel being used in the shared worker constructor