fix: wait for DOM readiness after MCP navigation

[skulidropek]

Summary

• make browser_navigate wait until document.body exists and document.readyState is interactive/complete
• prevent immediate browser_evaluate calls from racing navigation
• add unit coverage for the navigation readiness predicate

Verification

• cargo test --locked
• cargo clippy --locked --all-targets -- -D warnings
• runtime smoke: /tmp/dg-rust-browser-smoke-202651-proof with MCP/CDP/noVNC/RFB/X11 proof

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro Plus

Run ID: 6924b0ce-98cc-4c2f-b8cf-4fca8ad101fe

📥 Commits

Reviewing files that changed from the base of the PR and between c36f263 and ffe73e0.

📒 Files selected for processing (1)

• src/cdp.rs

---

📝 Walkthrough

Summary by CodeRabbit

• Bug Fixes
  • Increased reliability of navigation operations with enhanced readiness handling.
  • Improved error reporting for navigation failures with detailed status information.

Walkthrough

This PR adds an explicit post-navigation readiness gate to the CDP-driven browser automation flow. After page navigation, a new polling mechanism waits until the DOM is ready (document.body exists and readyState is interactive or complete) before returning, with a 10-second timeout and detailed error reporting.

Changes

Navigation Readiness Gate

Layer / File(s)	Summary
DOM readiness criteria and validation src/cdp.rs	NAVIGATION_READY_EXPRESSION constant defines a CDP Runtime JavaScript probe returning document.body presence and readyState. navigation_ready() helper interprets the probe result and requires both hasBody=true and readyState being interactive or complete.
Navigation readiness polling with deadline src/cdp.rs	std::time::Instant import added for deadline tracking. wait_for_navigation_ready() function implements a polling loop that repeatedly evaluates the readiness expression via CDP, sleeps between attempts, and returns a detailed error if the ~10-second deadline is exceeded.
Unit tests for readiness validation src/cdp.rs	New test validates navigation_ready() correctly gates on both hasBody and readyState, including the critical case where readyState=complete but hasBody=false must still be treated as not ready.

Estimated code review effort

🎯 2 (Simple) | ⏱️ ~12 minutes

Poem

🐰 A rabbit hops through the DOM today,
Waiting for the page to settle its way,
Body and state must both align—
Ten seconds to find that readiness sign!
With careful polls and errors so clear,
Navigation's now safer, no reason to fear.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 25.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: adding DOM readiness waiting after MCP navigation, which aligns with the primary modification in src/cdp.rs.
Description check	✅ Passed	The description is directly related to the changeset, providing clear context about DOM readiness checks, race condition prevention, and test coverage additions mentioned in the code summary.
Linked Issues check	✅ Passed	Check skipped because no linked issues were found for this pull request.
Out of Scope Changes check	✅ Passed	Check skipped because no linked issues were found for this pull request.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/mcp-navigation-dom-ready

---

_{Comment @coderabbitai help to get the list of available commands and usage tips.}