fix: honor the agent pin and the disabled setting when buttons open floating chats - #364
Conversation
A window created while the feature is off becomes unreachable after a minimize: the floating button and every floating command are gated by the setting, leaving only the Session Manager to recover it.
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Repository UI Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (3)
📝 WalkthroughWalkthrough
ChangesFloating chat routing
Estimated code review effort: 3 (Moderate) | ~20 minutes Possibly related PRs
Suggested reviewers: Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
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. Comment |
Description
Two pre-existing bugs in
runPromptInChat's floating branch, both surfaced by the sidebar double-init review (#363):The agent pin was silently dropped. Every view type carries an agent pin on its own channel — leaf views via Obsidian's view state (
state.initialAgentId), embedded blocks via the fence'sagent:field — but floating chats had no channel at all:openNewFloatingChat(initialExpanded, initialPosition)had no agent parameter, and the floating<ChatPanel>render passed noinitialAgentIdprop. A button withviewType: floatingand a pinned agent opened the default agent instead, and the prompt (including autoSend) was delivered there. The pin now rides the existing creation-parameter chain (openNewFloatingChat→createFloatingChat→mount→ component props) into ChatPanel's existinginitialAgentIdprop — the same receiving end the sidebar uses, so #363's directive-based init guard applies unchanged. The branch also stops reconstructing the target view id from a counter snapshot:openNewFloatingChatnow returns the created container and the id is read from it, matching the editor-tab and right-pane branches.Buttons bypassed the "Enable floating chat" setting. The setting (off by default) gates every re-entry point — the floating button and all four floating commands — but not creation via agent buttons or the in-window "new window" action. A window created while the feature is off becomes unreachable after a minimize (collapse is
display: none; only a Session Manager click can recover it).openNewFloatingChatis now the single choke point: while disabled it shows a notice and returnsnullbefore burning an instance id, and the button branch feeds that into the existingif (!targetViewId) return, so no undeliverable prompt is queued.A third commit aligns the two remaining unprefixed notices (both from the #341 button work) with the project-wide
[Agent Client]prefix convention (37 of 40 notices already use it).Related issue
None (tracked in the local backlog; found during the #363 multi-lens review).
Type of change
Checklist
npm run lintpasses ("Use sentence case for UI text" warnings are acceptable for brand names)npm run buildpassesTesting environment
viewType: floatingopens the pinned agent and delivers the prompt (with and without autoSend); unpinned button opens the default; commands, floating button, onload bootstrap instance, and the in-window "new window" action unchanged; with the setting disabled the button shows the notice, opens nothing, and queues nothing (re-enabling works normally); Session Manager shows the correct agent for pinned floating chatsScreenshots
N/A
Summary by CodeRabbit
New Features
Bug Fixes