trace: stepping stays in the view you're reading

Caught while demoing this in a live pane, not by a test: press Tab to read the
pseudocode, press ] once, and you're back in the disassembly.

_seek() follows the trace by navigating to the new PC, and navigating to an
ADDRESS opens the listing unless the decompiler is explicitly preferred. So
every step out of C dropped you out of C — the painting work of the last commit
was unusable in the view it was built for, from the first keypress.

_seek now passes prefer_decomp=(self._active == "decomp"), the same thing the
xref handler already does for the same reason.

Worth noting what it looks like when it works: stepping in pseudocode follows
execution INTO a callee and the view switches to that function's C, which is
what you want and what makes the decompiler painting worth having.

tests: +2 trace UI (23) asserting the view survives a step in both directions.
212/0 scenarios.

1 files changed, 6 insertions, 1 deletions

diff --git a/idatui/app.py b/idatui/app.py
index cc9cfa3..0fb1030 100644
--- a/idatui/app.py
+++ b/idatui/app.py
@@ -5495,7 +5495,12 @@ class IdaTui(App):
         self.query_one(TraceDock).show(t, self._t)
         self._paint_trail()
         if follow:
-            self._goto_ea(t.ip(self._t), push=False)
+            # Stay in whichever view you're reading. Without prefer_decomp a
+            # step from the pseudocode navigates to an address, which opens the
+            # listing — so stepping through C threw you out of C on the first
+            # keypress.
+            self._goto_ea(t.ip(self._t), push=False,
+                          prefer_decomp=(self._active == "decomp"))
 
     def _paint_trail(self) -> None:
         """Push the execution trail into the code views.