ns-input-accessory-dialogs
Installation
SKILL.md
input-accessory vs dialogs: suspend/restore around sheet presentations
A @nativescript/input-accessory composer bar is not part of the page's view hierarchy — the plugin reparents it into an inputAccessoryView hosted in the keyboard's own window (UITextEffectsWindow), kept on screen by holding first responder. UIKit z-orders that window above sheet-style presentations (PageSheet, FormSheet, popovers, alerts). So when a dialog opens over the page, the composer floats on top of it.
1. Why the two modal styles behave differently
| Presentation | What happens to the bar | What you must do |
|---|---|---|
| Fullscreen modal | Presenting view leaves the window → first responder resigns → bar disappears by itself. But UIKit never restores first responder, so it stays gone after dismiss. | restore() after dismiss only. |
| Sheet / popover / alert | Presenting view stays in the window → first responder is kept → bar stays visible, floating above the sheet. | suspend() on open and restore() on close. |
The plugin's own recovery hooks (didMoveToWindow) only fire for the fullscreen case. Sheets need the explicit pair.
2. Why naive fixes fail
resignFirstResponder()from app code: the plugin's auto-restore (textDidEndEditing→ re-becomeFirstResponder) exists so tapping away doesn't kill the bar — it will instantly bring the bar back. You cannot win this race from the JS side.- Hiding the NativeScript container view (
visibility,opacity): the view was reparented into the accessory container; collapsing it breaks the plugin's measure/layout cycle and leaves a blank blur bar docked anyway. - Dismissing the keyboard first:
dismissKeyboard()deliberately keeps the accessory-only state (that's its point) — the bar remains.