fix: focus the editor after creating Markdown notes

[n00ki]

Rationale

Creating a Markdown note with Cmd+N opened the new document but left focus outside the editor, so there was no visible caret and typing had no effect. This began when Tiptap autofocus and the path-change focus effect were removed while adding file properties.

Restoring either behavior would also focus the editor during ordinary file navigation, stealing focus from the sidebar. Editor focus should follow creation intent instead of every path change.

Hubble has two Markdown creation flows:

• Cmd+N, the native File menu, the command palette, and the toolbar create and open a note that is immediately ready for typing.
• The sidebar creates a placeholder note and opens its inline name field. It should keep that field focused until the user presses Enter, then transfer focus to the editor after the rename succeeds.

HTML creation keeps its existing sidebar focus behavior because it does not open the Markdown editor.

Alternatives considered

I considered restoring Tiptap's autofocus option or the previous path-change focus effect. Both would fix new-note creation, but they would also move focus into the editor whenever a user opened a file from the sidebar.

I also considered focusing the editor as soon as the sidebar creates a note. That would interrupt the inline naming step.

A continueEditing flag would express the desktop app's policy inside the shared sidebar. Instead, the sidebar reports the rename origin and how it was committed. The desktop app uses those facts to decide whether to focus the Markdown editor.

Summary

• Focus the Markdown editor on the next frame after successful note creation.
• Confirm that the created note is still active before moving focus.
• Keep Cmd+N, the native File menu, the command palette, and toolbar creation on the same focus path.
• After a sidebar note name is submitted with Enter, wait for the rename and focus the editor at the final path.
• Avoid an intermediate sidebar focus change during that handoff.
• Preserve existing focus behavior for HTML creation, blur commits, existing-file renames, and ordinary file navigation.
• Add regression coverage for creation focus, navigation races, and sidebar rename intent.

Testing

• pnpm check
• pnpm check:react-compiler
• pnpm build:desktop
• pnpm --filter @hubble.md/ui test
• pnpm --filter @hubble.md/desktop test
• Verified Cmd+N and command palette creation in the Electron app.
• Verified that submitting a new sidebar note name focuses the Markdown editor without first focusing the sidebar tree.
• Verified that new HTML apps and existing-file renames retain sidebar focus.
• Verified that ordinary sidebar navigation does not focus the editor.

[vercel]

@n00ki is attempting to deploy a commit to the bholmesdev's projects Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Overview

Restores Markdown editor focus after intentional note creation without focusing on ordinary navigation. Cmd+N / menu / palette go through focusMarkdownEditorAfterRender; sidebar new-note Enter reports { origin, commit } and desktop focuses only after a successful rename. HTML create, blur commits, existing renames, and path changes stay on prior focus behavior. Solid race guard (currentPath check) and useful unit coverage.

Concerns

• No blocking issues.
• Sidebar tests assert rename metadata, not the handsOffFocus side effect (tree not focused). Optional follow-up.

Comments audit

• fileActions.test.ts / Sidebar.test.tsx: vitest env + existing @ts-expect-error pattern only. No new prose comments to flag.
• Unchanged path-rewrite comments left intact.

Tests audit

• fileActions.test.ts: success focus, failed create, navigation race — good.
• Sidebar.test.tsx: Enter origin/commit for new-note / rename / new-html — matches the desktop contract.
• renameMarkdownFile return value asserted.

Verdict

Found: 0 critical, 0 important, 1 suggestion

Approve with nits

---

Reviewed by a Warp Factory agent.

[github-actions]

💡 [SUGGESTION] This only checks onRenameFile args. The regression risk is handsOffFocus skipping navRef.focus() / pendingFocusDisplayPath on new-note Enter. Assert document active element stays off the tree (or that nav is not focused) after submit so that handoff cannot regress silently.

[github-actions]

Overview

Follow-up review of focus-after-create for Markdown notes. Cmd+N / menu / palette still go through focusMarkdownEditorAfterRender after successful create; sidebar new-note Enter reports { origin, commit } and desktop focuses only after a successful rename. HTML create, blur commits, existing renames, and ordinary navigation keep prior focus behavior.

Follow-up status

• Prior suggestion (assert handsOffFocus skips tree focus): addressed. New-note Enter test spies tree.focus, flushes mocked rAF, and expects no tree focus.

Concerns

• No blocking issues in the delta or remaining PR surface.

Comments audit

• fileActions.test.ts / Sidebar.test.tsx: vitest env directive + existing @ts-expect-error for react-dom only. No new prose comments to flag.
• Unchanged path-rewrite comments left intact.

Tests audit

• fileActions.test.ts: success focus, failed create, navigation race — still good.
• Sidebar.test.tsx: Enter origin/commit for new-note / rename / new-html; new-note path now covers the handsOffFocus side effect.
• renameMarkdownFile return value asserted.

Verdict

Found: 0 critical, 0 important, 0 suggestions

Approve

---

Reviewed by a Warp Factory agent.