Our structured serialization implementation had its own bespoke encoder
and decoder to serialize JS values. It also used a u32 buffer under the
hood, which made using its structures a bit awkward. We had previously
worked around its data structures in transferable streams, which nested
transfers of MessagePort instances. We basically had to add hooks into
the MessagePort to route to the correct transfer receiving steps, and
we could not invoke the correct AOs directly as the spec dictates.
We now use IPC mechanics to encode and decode data. This works because,
although we are encoding JS values, we are only ultimately encoding
primitive and basic AK types. The resulting data structures actually
enforce that we implement transferable streams exactly as the spec is
worded (I had planned to do that in a separate commit, but the fallout
of this patch actually required that change).
This change implements following behavior defined in the spec:
https://html.spec.whatwg.org/multipage/web-messaging.html#examples-5
> The start() method, whether called explicitly or implicitly (by
setting onmessage), starts the flow of messages: messages posted on
message ports are initially paused, so that they don't get dropped on
the floor before the script has had a chance to set up its handlers.
Now we don't read bytes from the underlying transport socket until the
message port transitions to the enabled state. This required the
following places to explicitly enable the message port, because now,
when it actually matters, we must do so, or otherwise sent messages will
get stuck:
- `onmessage` attribute setter in DedicatedWorkerGlobalScope, because
it implicitly sets the onmessage handler for the worker's underlying
port.
- Stream API operations where the message port enabling steps were
previously marked as FIXMEs.
Also push the onconnect event for the initial connection.
This still doesn't properly handle sending an onconnect event to a
pre-existing SharedWorkerGlobalScope with the same name for the same
origin, but it does give us a lot of WPT passes in the SharedWorker
category.
This is to differentiate the agent representation for the parent
process for the WorkerAgent in the child process which is actually
hooked up to the javascript VM.
I am not sure if this is a good name, but I can't really think of
anything better which is consistent with the names used by the rest
of the codebase.
2025-04-25 14:07:51 +02:00
Renamed from Libraries/LibWeb/HTML/WorkerAgent.cpp (Browse further)
