❌ 4 Tests Failed:

To view more test analytics, go to the Test Analytics Dashboard
_{📋 Got 3 mins? Take this short survey to help us improve Test Analytics.}

@mrobinson this PR is ready, can you help review? Thank you.

This implementation works, and I can see the appeal of reusing the existing GetCookiesForUrl message. However, polling while spinning the event loop has a subtle performance issue—if there's nothing else happening that triggers an event loop spin, the response will sit unprocessed. In the case of servoshell, this would happen if the page isn't animating and the user doesn't trigger any inputs:

Is this a big deal? Hard to say; I could imagine some embedding scenarios where pauses without user inputs could happen. However, there's another design possible which would avoid any polling:

1. add a new CookieOperationId type
2. add a new CoreResourceMsg GetCookiesForUrlAsync message that takes a CookieOperationId, CookieSource, and URL
3. add a response message to NetToEmbedderMsg in components/net/embedder.rs that takes a CookieOperationId and Vec<Cookie<'static>>
4. add a GenericEmbedderProxy<NetToEmbedderMsg> member to ResourceChannelManager
5. when the resource thread processes the GetCookiesForUrlAsync, send the response on the new embedder proxy
6. when the new NetToEmbedderMsg message is received, the site data manager invokes the appropriate pending cookie request callback

4. add a GenericEmbedderProxy<NetToEmbedderMsg> member to ResourceChannelManager
5. when the resource thread processes the GetCookiesForUrlAsync, send the response on the new embedder proxy
6. when the new NetToEmbedderMsg message is received, the site data manager invokes the appropriate pending cookie request callback

I think it's worth to implement a more comprehensive solution. I have a draft at local. There are some points need to discuss:

• When resource thread process_msg, we already has a http_state which contains a embedder_proxy, so step 4 and 5 can be done without a new proxy?
  

  servo/components/net/resource_thread.rs

  Lines 403 to 407 in 80e8441

  	fn process_msg(
  	&mut self,
  	msg: CoreResourceMsg,
  	http_state: &Arc<HttpState>,
  	protocols: Arc<ProtocolRegistry>,

• However, I don't know how to invoke pending callback without the spin loop. As I know, Servo also handles NetToEmbedderMessage in the spin loop:
  

  servo/components/servo/servo.rs

  Line 217 in 80e8441

  Message::FromNet(message) => self.handle_net_embedder_message(message),

• However, I don't know how to invoke pending callback without the spin loop. As I know, Servo also handles NetToEmbedderMessage in the spin loop:

The difference is that GenericEmbedderProxy contains an event loop waker, so any message sent on the channel also notifies the embedder to spin the event loop.

When resource thread process_msg, we already has a http_state which contains a embedder_proxy, so step 4 and 5 can be done without a new proxy?

If you can access an existing embedder proxy then you can use that.

General question: How important is the asynchronous version? The other APIs in SiteDataManager work synchronously. I would rather add support for asynchronous operation to all APIs, rather than just a special asynchronous version of a single API point.

General question: How important is the asynchronous version? The other APIs in SiteDataManager work synchronously. I would rather add support for asynchronous operation to all APIs, rather than just a special asynchronous version of a single API point.

@mrobinson
The purpose is to support HOS WebCookieManager.
There is a pair of sync and async for each API: get cookie, set cookie, save cookie, delete all cookies and delete session cookie.
The get cookie is the highest priority.
Do you want me to add more in this PR?

@mrobinson I've updated the solution to handle asynchronous callback and response data for all APIs, and implement set_cookie_for_url_async.
Other async APIs will be addressed in #44166.