fix: stop a de-focusing block from re-grabbing focus

[jameswolensky]

Fixes#3428

Problem

With two web blocks open, clicking from one into the other makes both webviews unresponsive — buttons/links don't click, the URL bar can't be edited, typing does nothing. Only the block header icons still respond.

webview-focus flaps continuously between the two webview ids and null; focus is granted then revoked within a few ms, so no input lands. Terminal→web is fine; only web→web breaks.

In BlockFull, blockClicked is state and lags one commit, so the focus effect also runs while a block is losing focus (blockClicked still true, isFocused false). The effect could not distinguish a real click from a focus loss, so the de-focusing block re-grabbed both DOM focus (setFocusTarget) and logical focus (focusNode). With two web blocks each doing this, they fight indefinitely. A single webview settles because there is no competitor.

Fix

Use focusWithin (does DOM focus currently sit inside this block) to tell the two cases apart:

• Pull DOM focus in (setFocusTarget) only when this block is the focused node.
• Claim logical focus (focusNode) only when the click actually landed inside this block.

A block that is losing focus now satisfies neither condition, so it no longer re-grabs focus, and the two web blocks stop fighting.

Test Plan

• Open two web blocks, click A → B → A — verify links/buttons click, URL bar edits, and typing works in both (previously dead)
• Verify webview-focus no longer flaps in the logs while idling on a web block
• Terminal → web focus still works
• Clicking an unfocused block still focuses it (click-to-focus)
• Single web block behaves as before

[CLAassistant]

All committers have signed the CLA.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository UI

Review profile: CHILL

Plan: Pro

Run ID: 6806b61c-eca7-46f7-ad66-294f5d5f0250

📥 Commits

Reviewing files that changed from the base of the PR and between c99022c and 2e1f21c.

📒 Files selected for processing (1)

• frontend/app/block/block.tsx

---

Walkthrough

Updated BlockFull focus-management guards so setFocusTarget() runs only when DOM focus leaves a still-focused block, while nodeModel.focusNode() runs only when model focus is absent but DOM focus remains within the block. Added comments documenting state lag and de-focusing protection.

Estimated code review effort: 2 (Simple) | ~10 minutes

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly matches the main fix: preventing a losing block from re-grabbing focus.
Description check	✅ Passed	The description directly explains the focus-flap bug and the focusWithin-based fix.
Linked Issues check	✅ Passed	The change addresses #3428 by stopping the losing web block from reclaiming focus, keeping both webviews interactive.
Out of Scope Changes check	✅ Passed	No unrelated code changes are evident beyond the focus-management fix in block.tsx.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

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