An events route exists between WebDriver <-> Constellation <-> ScriptThread. Should we use it to receive response from ScriptThread? It means merge WebdriverData.sync_channel and WebdriverData.load_channel. Other option is let ScriptThread sends reply directly to WebDriver, similar to WebDriverScriptCommand

I prefer the other option. Right now sync_channel in Constellation does nothing except forwarding WebDriverInputComplete from ScriptThread back to WebDriver Server.

Mostly LGTM, except that perform_scroll also requires similar sync like the rest. See the comment below :)

Noted. We already have load_channel, need to check more if we can use it.

Some points to discuss:

• An events route exists between WebDriver <-> Constellation <-> ScriptThread. Should we use it to receive response from ScriptThread? It means merge WebdriverData.sync_channel and WebdriverData.load_channel. Other option is let ScriptThread sends reply directly to WebDriver, similar to WebDriverScriptCommand

I also prefer the latter. If there's an existing design that works, we should reuse it so that it's easier for future developers.

• In current implementation, WebDriver creates a temporary pair of Sender and Receiver and pass the Sender with each command to constellation or ScriptThread. Should we make permanent channels?

A temporary pair seems fine (I'm assuming it's the current mechanism in script commands). WebDriver is not performance-sensitive code, so it's better to follow existing design.

Some points to discuss:

• An events route exists between WebDriver <-> Constellation <-> ScriptThread. Should we use it to receive response from ScriptThread? It means merge WebdriverData.sync_channel and WebdriverData.load_channel. Other option is let ScriptThread sends reply directly to WebDriver, similar to WebDriverScriptCommand

I also prefer the latter. If there's an existing design that works, we should reuse it so that it's easier for future developers.

• In current implementation, WebDriver creates a temporary pair of Sender and Receiver and pass the Sender with each command to constellation or ScriptThread. Should we make permanent channels?

A temporary pair seems fine (I'm assuming it's the current mechanism in script commands). WebDriver is not performance-sensitive code, so it's better to follow existing design.

ScriptThread handles script command immediately.
For input command, because ScriptThread stores input events to handle later, if we do the same, ScriptThread needs to store ipc channels for each command in correct order.
Are you ok with that way?

In addition, there is an existing route between WebDriver and ScriptThread, WebDriver are using both options.

Tests: ./mach test-wpt --product servodriver -r tests\wpt\tests\webdriver\tests\classic\element_click\events.py pass if hit_testing pass.

Maybe you can add this link #36676 (comment) in the PR message so that people coming by can better understand the context of hit_testing.

Thanks! Just a couple notes here. I have not reviewed the webdriver portions as I'm probably not the best person for that and have just focused on the embedding layer.

I've updated. Thank you!

...as lot of this will need to change when we move our WebDriver implementation to servoshell.

Sorry if I'm out of sync. I thought WebDriver should not depend on servoshell?

It is under discussion in #36714.
You can check the last comment .

If we can enable WebDriver conformance check on CI, it is a huge convenience for later WebDriver development.

I definitely agree with this. I think maybe we need a more generic mechanism for this in the WebView API. Currently you send an event to the WebView via WebView::notify_input_event and then unprocessed key events are reported via WebViewDelegate::notify_keyboard_event. Likely we need some sort of WebViewDelegate::notify_processed_input_event which reports whether it was handled or not. In the case it wasn't handled, the embedder is responsible for sending the event back to the toolkit. If WebView::notify_input_event is responsible for setting an id on the internal input event and returning it, WebViewDelegate::notify_processed_input_event can also include that id. This could be used by WebDriver to accomplish what you are doing here.

Sorry if I'm out of sync. I thought WebDriver should not depend on servoshell?

Ultimately, WebDriver should be testing the embedding API, so it will need some way of controlling servoshell in order to create and add WebViews to the interface. This could be done either by making the webdriver crate part of servoshell or asking for callbacks which servoshell provides (to avoid a dependency). Right now having webdriver sitting in the middle of the Servo stack is causing a lot of issues.

Oh, I forgot to mention that an added benefit of having WebDriver use the embedding API is that it ensures that the embedding API is rich enough.

Thank you! I've pushed a small commit that fixes a couple nits so minor I didn't want to bother you with them. Thank you so much for the patience here and apologies for the long review process.

It is totally ok. Thanks for your fixing.

Looks like there are a couple build issues on OpenHarmony which must use the new constructor for embedder input events.