0.50.1 breaks XPath / DOM behavior; keep 0.48.1 pinned until fixed

[1cu]

Summary

We upgraded a downstream consumer from nodriver 0.48.1.post1 to 0.50.1.post1 and hit behavior changes that break browser automation flows. Until these regressions are fixed upstream, we are keeping the downstream project pinned to 0.48.1.

Why this matters

Upstream 0.50.1’s release notes warn about behavior changes (flat mode / iframe inclusion / selector semantics). In practice, that warning is relevant for us: a few of our critical DOM-selection paths changed behavior or failed outright after the upgrade.

This is not a theoretical compatibility note — it directly affects real automation flows that need stable selector behavior and predictable timing.

Observed failures

1) Tab.xpath() can fail with DOM.enable

In our environment, calling Tab.xpath() on nodriver 0.50.1.post1 raised:

ProtocolException: 'DOM.enable' wasn't found [code: -32601]

The stack trace went through:

• nodriver/core/tab.py → Tab.xpath()
• nodriver/core/connection.py → Connection.send()

The failure happened because Tab.xpath() internally tries to enable the DOM domain before searching. That path is now unreliable in the upgraded version.

2) Iframe / selector semantics changed

Upstream 0.50.1 warns that more operations now include iframe content and that find() behavior changed. Our automation depends on stable selector scoping, so this is risky even when it does not hard-fail.

3) Downstream live DOM verification needed a workaround

Our consumer project had to add a local XPath workaround to avoid the broken native Tab.xpath() path. That is a sign the upstream behavior is not stable enough for a safe upgrade.

Reproduction sketch

A minimal reproduction is likely something like:

import asyncio
import nodriver

async def main() -> None:
    browser = await nodriver.start()
    tab = await browser.get("about:blank")
    await tab.xpath("//html")

asyncio.run(main())

On the affected version, this can fail with the DOM.enable protocol error above.

Impact on downstream consumers

The consumer project that exposed this issue uses nodriver for:

• XPath-based element lookup
• text-based lookup
• captcha / iframe detection
• shipping / condition / combobox flows
• timeout-sensitive navigation and download workflows

So this is not a niche API edge case; it affects core browser automation.

What needs to be fixed before upgrading

Please consider this issue resolved only when:

1. Tab.xpath() works reliably again without depending on unavailable protocol commands.
2. Selector scope / iframe behavior is documented and stable.
3. A downstream consumer can run realistic DOM verification without repo-local workarounds.
4. The upgrade does not introduce new timeout or readiness regressions.

Current recommendation

Until the above is resolved, downstream consumers should stay pinned to 0.48.1.

Notes for future maintainers

If you pick this up later, the fastest path is probably:

1. reproduce the Tab.xpath() failure on 0.50.1,
2. identify the protocol/API change that caused it,
3. either restore compatibility or provide a stable replacement,
4. then rerun downstream DOM/timeout verification before recommending the upgrade.

[1cu]

Kleinanzeigen-bot switched to 0.50.3 upstream with a local pos_install hack: Second-Hand-Friends/kleinanzeigen-bot#1071