From 1e246a1136c5b5d4d84f6a796391007fa7ad0abc Mon Sep 17 00:00:00 2001 From: blasty Date: Sun, 26 Jul 2026 00:25:35 +0200 Subject: load dialog: reachable address field, project mode, and a way back from a bad answer MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Three bugs, reported together, with one shared root: you couldn't get to the address field, so the address went into the processor filter, so IDA got a nonsense processor name and refused to open — and the app dead-ended with a misleading error. **Tab never reached any modal.** Binding("tab,shift+tab", "toggle_view", priority=True) is an APP binding, and priority bindings run before the focus chain. Nothing in any dialog in this app could ever be tabbed to; the load dialog is just where it finally mattered. action_toggle_view now hands the key back when a modal is up, which fixes it everywhere. **...and DOM order was the wrong tab order anyway.** focus_next() stopped at the processor list, which is arrow-driven and has nothing to type. LoadOptionsScreen overrides it to cycle the two fields you actually type into. **...and the dialog outgrew the terminal.** With the palette's default max-height the 21-row list pushed the address field and help line off the bottom of the screen. Nothing errors — the field simply isn't there, which reads as "Tab does nothing". Capped per-dialog. **Project mode never asked.** _should_ask_load_options bailed on `self._project is not None` with the comment "project mode carries per-binary options already" — true only if someone had already filled them in. A raw blob added to a project got the silent x86-at-0 treatment the dialog exists to prevent. Now asked at boot AND on switching to an undescribed binary, and the answer is written back to the project entry (Project.set_load), so it is asked once per binary, not once per run. **A rejected answer dead-ended.** Getting a processor wrong is an ordinary mistake; it left an empty app with "connect failed: worker exited (code 1)" and a message blaming a locked .i64. The worker now names the real suspect when load switches were in play, and the app re-opens the dialog instead of giving up. Verified with real keys in a tmux pane, which is the only way any of this shows up: Tab -> address field -> 0x8000000 -> Enter -> 35 functions at 0x80039AC; a bogus processor -> "those load options were rejected — try again" with the dialog back; project mode -> asks, loads at the right base, and the answer is in the project file. tests: +3 scenarios (Tab moves focus under a modal, lands on the address field, cycles back). 202/0 scenarios, 39/0 project, 32/0 formats, 30/0 project UI. docs/TEXTUAL_NOTES.md gets the priority-binding and clipped-modal traps. --- docs/TEXTUAL_NOTES.md | 30 ++++++++++++++++++++++++++++++ 1 file changed, 30 insertions(+) (limited to 'docs') diff --git a/docs/TEXTUAL_NOTES.md b/docs/TEXTUAL_NOTES.md index 4bf7fcb..059b47c 100644 --- a/docs/TEXTUAL_NOTES.md +++ b/docs/TEXTUAL_NOTES.md @@ -80,3 +80,33 @@ Hard-won Textual behaviour and the patterns this app relies on. Pairs with failures. Re-run on a warm session before trusting a regression. - Edits mutate the `.i64` — revert renames (via API) for idempotency; use a PID-unique temp name to dodge collisions from a prior crashed run. + + +## A priority app binding fires even under a modal + +`Binding("tab,shift+tab", "toggle_view", priority=True)` on the App runs before +the focus chain, so Tab never reached ANY dialog — nothing in a modal could be +tabbed to, in this app, ever. It looked like a bug in one dialog (the load +options address field was unreachable) and was actually app-wide. + +The fix is in the action, not the binding: if a modal is up, hand the key back. + +```python +def action_toggle_view(self): + if self.screen is not self.screen_stack[0]: + self.screen.focus_next() + return +``` + +Related: DOM order is rarely the tab order you want. In a dialog with a filter +box, an option list and a second field, `focus_next()` stops at the list — which +is arrow-driven and has nothing to type — so text meant for the second field +lands in the filter. Override `focus_next`/`focus_previous` on the screen to +cycle the fields people actually type into. + +## A modal can outgrow the terminal and clip its own controls + +`#pal-list { max-height: 24 }` plus a 21-row list pushed the address field and +help line off the bottom of the screen. Nothing errors; the field is simply not +there, which reads to the user as "Tab does nothing". Cap the scrollable part +per-dialog so the controls below it are always visible. -- cgit v1.3.1-sl0p