[Astro-Han]

Summary

On macOS since #6698 the composer does not accept typing: clicking it does nothing and keys are dropped.

#6698 made NshView::can_reach treat a view whose own pointerEvents is box-none as unreachable, and every text-input path now asks can_reach (acceptsFirstResponder, focus_editor, auto_focus / end_batch, focused_editor). RichEditor keeps its caret sink input box-none (rich_editor/view/render.rs) so presses fall through to the text it draws, so no RichEditor on macOS could take keyboard focus, and Maka's composer is one.

pointerEvents decides where presses go, not whether an input can hold the keyboard, so an input's own box-none no longer blocks it. A box-none ordinary view is still neither a key stop nor a press target, and ancestors that are hidden, none or box-only keep revoking focus as #6698 intended.

Root cause

• At 57470e4c15 (before fix(nsh): preserve GTK4 focus barrier and enforce macOS subtree reachability #6698) the desktop suite gets past its first text entry; at 11c06b124d every case stops there (the requested editor was not ready for text input), locally and in CI's native-macos.
• Restoring only text_input.rs from before fix(nsh): preserve GTK4 focus barrier and enforce macOS subtree reachability #6698 brings typing back.
• A temporary log in can_reach showed the rejected view is the input itself, mounted box-none.

Verification

• terminal_native (nsh-platform-macos, --features terminal): 6/6 pass, including fix(nsh): preserve GTK4 focus barrier and enforce macOS subtree reachability #6698's hidden_and_clipped_subtrees_exclude_pressables_and_revoke_focus. The new box_none_input_takes_keyboard_focus_and_typing (an autofocused box-none input gets focus and takes a typed key) fails without the fix.
• native-desktop (maka-cli, desktop-tests) on macOS: 19 of 22 pass, up from failing at the first text entry. The remaining three (desktop_file_gestures_preserve_drafts_and_stage_an_image, desktop_remembers_folders_without_restoring_unsent_drafts, desktop_steering_freezes_each_message_and_queue_is_one_shot) also fail at 57470e4c15, before fix(nsh): preserve GTK4 focus barrier and enforce macOS subtree reachability #6698, so they are not part of this regression.
• node scripts/ci.mjs check format and cargo fmt on nsh-platform-macos: clean.

AI use

Select exactly one:

• No generative tool made a substantive contribution
• Generative tooling made a substantive contribution

Tool(s) and scope: Claude Code bisected and diagnosed the regression, wrote the fix, the test and this description, and ran the checks above.

Checklist

• Tests cover the change and fail without it
• Format, typecheck and the affected suites pass locally

Does this PR entail a change in behavior?

• Yes — described under Summary above
• No

[Astro-Han]

I reviewed all three changed files at a1cea997b4728551aff5d72053a6cae7981375bf and traced RichEditor's visually transparent native input sink into the macOS focus-admission paths. The reviewed head and merged 74765152 have identical Git trees, as does the hosted PR checkout.

No confirmed P0–P2 finding. The existing sink in rich_editor/view/render.rs is one point wide and deliberately pointerEvents: box-none. The previous reachability predicate rejected that input before the responder, autofocus and focused-editor paths could use it. This patch exempts an input's own box-none setting while continuing to reject an ordinary box-none view, hidden/unattached views and blocked ancestor paths. I checked the actual old and new method bodies with controlled native-object responses: 20 ancestry/state cases per version, including the old rejection and new acceptance of the box-none input. This is a source-level controlled check, not a local AppKit run.

The current PR macOS job 128661168164 passes 86 platform tests and all six surface tests. The new box_none_input_takes_keyboard_focus_and_typing case passes in 2.243s, and the existing hidden/clipped-subtree test also passes. The desktop suite now passes its first three cases; the earlier 6fd run 42453547678 failed at its first text-entry wait.

Complete desktop acceptance remains unresolved. The PR job fails its fourth case, desktop_creates_only_on_first_submission_and_preserves_the_confirmed_snapshot, after 65.616s because the expected selected.png draft is absent (observed: Null, desktop_new_session.rs:265), leaving 18 cases unrun. I have not established that failure's cause or independently reproduced the author's older-baseline comparison. The merged 74765152 run 42460736390 was still running when checked; I am not treating the author's local 19/22 result as the hosted result.

This narrow fix does not replace #6705's additional pointer pass-through, Tab and paste work or the outstanding broader migration review. I did not run AppKit or real IME locally. No schema or wire changes.

---

Automated review notice: This comment was posted by an automated review agent operated by Astro-Han. It is not an independent human review and does not replace one.