Imperfect send() kills browser, provides no exception or hint of problem

[omegahacker]

While trying to move away from seleniumwire, I first tried Playwright (aggressively focused on "user testing" to the exclusion of automation), then nodriver (ran into obvious fatal bugs), and now I'm trying to use zendriver.

The problem is, as I'm trying to implement various things that I need for my application, including interception with the goal of aggressive caching, and now passkeys, I keep running into situations where as I work on a given CDP command via send(), the browser will simply vanish without warning and my code will continue on as if nothing happened. There are clearly issues in how I'm constructing the CDP commands, but there are no error messages, exceptions, or anything else coming from Zendriver to either tell me there's a problem, or help me debug it.

Right now I'm trying to use web_authn.add_credential, and as part of my debugging I've added a print(tx.message) in Connection.send() right before it goes to the websocket, and it's not even getting that far:

auth_id = await page.send(cdp.web_authn.add_virtual_authenticator(...))
print(auth_id)
print("before add_credential")
await page.send(cdp.web_authn.add_credential(authenticator=auth_id, credential=cred)
print("after add_credential")
await page.sleep(10)

What I get from this is:

->CDP {"method": "WebAuthn.addVirtualAuthenticator", "params": {"options": { "protocol": "ctap2" ...........
c7ce1845-8caf-4877-bdd3-22e03d3a7971
before add_credential
->CDP: {"method": "Browser.close", "params": [], "id": 5}
**EOF**

It appears that the add_credential call is literally screwing things up so badly that maybe an atexit() is triggering and closing the browser, or ....?

My previous descent down this rabbithole was for the add_virtual_authenticator call, when various code snippets indicated that I should have protocol="ctap2" rather than protocol=cdp.web_authn.AuthenticatorProtocol.CTAP2 (that's a whole other thing that should be fixed...). In chasing through the code, I localized it to the VirtualAuthenticatorOptions.to_json() call, which was blindly calling self.protocol.to_json() on what turned out to be a string rather than an AuthenticatorProtocol object. This obviously would throw an exception, except I never actually got an exception from anywhere, it just did the same thing of crashing out the browser and moving on as if nothing happened, until the next call in my code tried to talk to the browser and failed.

I'm going to try to dig into this and figure out exactly where this particular call is going wrong, and I'm going to try to figure out why it just silently fails.

To be continued...

[omegahacker]

Update: now, for no reason I can identify, I'm actually getting an exception printed out that finally tells me that add_credential wants authenticator_id rather than authenticator as a parameter. But it hasn't really changed the situation - I still can't get past the send(add_credential):

->CDP: {"method": "WebAuthn.enable", "params": {}, "id": 0}
->CDP: {"method": "WebAuthn.addVirtualAuthenticator", "params": {"options": {"protocol": "ctap2", "transport": "internal", "hasResidentKey": true, "hasUserVerification": true, "isUserVerified": true}}, "id": 0}
got authenticator 1b3530b6-f7ce-4908-bd9b-a397f3b443c7
sending add_credential
->CDP: {"method": "WebAuthn.addCredential", "params": {...............}}, "id": 0}
->CDP: {"method": "Browser.close", "params": [], "id": 6}
Unhandled exception in asyncio atexit callback <function Browser.create.<locals>.browser_atexit at 0x7fb1aaf15260>: Executor shutdown has been called
Traceback (most recent call last):
..................
  File "test.py", line 95, in main
    await page.send(cdp.web_authn.add_credential(authenticator_id=authenticator,credential=authn_cred))
  File ".venv/lib/python3.11/site-packages/zendriver/core/connection.py", line 587, in send
    raise e
  File ".venv/lib/python3.11/site-packages/zendriver/core/connection.py", line 583, in send
    return await tx  # type: ignore
           ^^^^^^^^
zendriver.core.connection.ProtocolException: Invalid parameters
command:WebAuthn.addCredential
params:{'authenticatorId': AuthenticatorId('1b3530b6-f7ce-4908-bd9b-a397f3b443c7'), 'credential': {.............}} [code: -32602]

I'm not sure where the Browser.close message is coming from, unless it's maybe an async response to the browser having already crashed out?

Next step was turning on logging with:

logging.basicConfig(
  level=logging.DEBUG,
  format='%(asctime)s - %(name)s - %(levelname)s - %(message)s'
)

But all I get are truncated messages from websockets that are of no use:

2026-07-15 12:17:38,317 - websockets.client - DEBUG - > TEXT '{"method": "WebAuthn.addVirtualAuthenticator", ...fied": true}}, "id": 0}' [203 bytes]
2026-07-15 12:17:38,317 - websockets.client - DEBUG - < TEXT '{"id":0,"result":{"authenticatorId":"86e13add-4...e4-8d78-314227232123"}}' [76 bytes]
2026-07-15 12:17:38,317 - websockets.client - DEBUG - > TEXT '{"method": "WebAuthn.addCredential", "params": ...g4MDA4MA=="}}, "id": 0}' [507 bytes]
2026-07-15 12:17:38,320 - websockets.client - DEBUG - < TEXT '{"method":"Target.targetInfoChanged","params":{...2B21D853DEE8274F128"}}}' [259 bytes]

It too waay too long to find a means of preventing the truncation, finally found that you have to set an environment variable WEBSOCKETS_MAX_LOG_SIZE. Once I had proper logs, I found this:

2026-07-15 12:24:50,299 - websockets.client - DEBUG - < TEXT '{"id":0,"error":{"code":-32602,"message":"Invalid parameters","data":"Failed to deserialize params.credential.privateKey - BINDINGS: invalid base64 string at position 173"}}' [173 bytes]

Even though I got this passkey's privateKey from my existing (functioning and using the passkey) Selenium code, apparently it's not actually valid base64. I'll have to either figure out how to reformat it, or just create new passkeys once I have the credential readback mechanism working.

However, this still ends up being a problem with zendriver not relaying the error message to me as part of the add_credential call, but instead deciding to simply shut down the browser entirely. I guess I'll have to move on to tracking down how the zendriver CDP communications work and how responses from the browser are handled to figure out why the Chrome error message is causing all of this...