When responding to commands, or sending events the contained payload needs to be serialized. We should get the basics implemented so that the logging feature can be implemented.

It would be good to know which commands would be necessary, and as such which data types are required.

The log.entryAdded event contains the following entries:
https://w3c.github.io/webdriver-bidi/#types-log-logentry

For the next milestone 2 we might want to have more than just basic support. Updating the summary for now, triage will happen early in September.

This is required for milestone 2 to complete the implementation for log.entryAdded and to return all kinds of element types.

We will first implement a basic serialization/deserialization for simple types, adding the necessary entry points that should be used for commands, responses and events serialization.

Then we will file follow ups to implement more complex types and complete the serialization/deserialization logic.

We missed to update the summary of the bug yesterday. By shifting the amount of work for this bug we would also have to adjust the points. Let discuss that on Monday.

It might be good to cover these data types initially:

Null
Undefined
String
Number
Boolean

https://github.com/web-platform-tests/wpt/blob/c6d1a640c94adc163c4304ec5fd61e50512dde3a/resources/channel.sub.js#L324-L554 has something a bit like the initial spec draft (although without some complexity). I'll keep updating that as I implement the associated wpt feature, and the idea is to be close to BiDi.

Some more details from our triage discussion:

• Consider complex types so no further refactoring is needed after implementing the above proposed basic types.

• Maybe we could use our CDP implementation to see how serialization and deserialization could be done.

• For JS objects we may wanna have a constructor field so that non-platform types (like for the application itself) could be instantiated if possible.

I just saw the implementation of self.structuredClone() (bug 1722576) and wonder if that could be something helpful for us given that it also targets the transfer of objects between realms. That sounds similar to our needs, including the transfer between the parent and content processes.

James, what do you think? I do not see any structured cloning reference in the BiDi spec at the moment.

It's similar but it's not the same. The way structured clone works, the actual transfer format isn't exposed, whereas we actually need to deal with the serialized message rather than making that part opaque. We may also have different requirements around e.g. custom objects which can't be directly recreated in the target environment.

Thanks James. We also discussed that in this weeks Bidi sync meeting, and I'm going ahead with a basic implementation.

Note that we now have an actual event that can be used to test the serialization code which is log.entryAdded. So there is no reason of being blocked anytime longer on bug 1693834.

Also I noticed that we do not yet have deserialization from RemoteValue covered in the WebDriver BiDi spec. This will be added with the PR for callFunction via https://github.com/w3c/webdriver-bidi/pull/142. As such I would propose to only land the serialization code for now and post-pone deserialization until the PR got merged. Julian, do you agree? If yes, we should make this a 2-point bug.

Hm, regarding points... lets see how tricky it is to get the WebDriver tests written. We would also need the appropriate code in the BiDi Python client that produces the right types on the consumer side.

Sounds fine to postpone deserialization until it's actually needed. But 2 points seems too low in anycase I'd keep 8 for this one.

Yes, we should leave at 8 points given the complexity as needed to get the wdspec tests running. I'll file a follow-up for the deserialization piece.

Depends on D131603

Depends on D131604

Depends on D131605

https://hg.mozilla.org/mozilla-central/rev/7f16b9f78b81
https://hg.mozilla.org/mozilla-central/rev/0dce12e803e3

We only landed 2 patches of the stack, especially the test was not landed. Was this intended or should we land them now?

Very suspicious! I'm sure that all 4 were marked to be landed. I triggered the landing of the remaining two patches now. Thanks a lot for noticing that.

https://hg.mozilla.org/mozilla-central/rev/95d37ec74f93
https://hg.mozilla.org/mozilla-central/rev/780ea53e87fa

https://hg.mozilla.org/mozilla-central/rev/811d8a224682