From 9028f8175bda63d6a85e5a2dee2b4039020317a4 Mon Sep 17 00:00:00 2001 From: srdusr <99972264+srdusr@users.noreply.github.com> Date: Tue, 9 Jun 2026 14:35:00 +0200 Subject: Mouse support: wheel scroll everywhere, right-click context menus Explicitly requested - this is a real terminal app meant to work in any terminal (the name is a naming convention, not a tmux runtime dependency), and should be genuinely mouse-driven, not keyboard-only. Enabled via tea.WithMouseCellMotion() (SGR mouse mode, the same protocol nvim and most modern TUI apps use); coexists with tmux's own mouse mode the same way it would for any other terminal app. Scope was decided by a real, verified library constraint, not convenience: bubbles/table exposes no way to learn its own scroll offset (confirmed by reading its source - no YOffset accessor, the rendered window comes from unexported fields via a second internal layer of viewport scrolling on top of that). Mapping a click's screen coordinates to a specific table row can't be done without reaching into that library's private internals, which this deliberately doesn't do - silently selecting the wrong row on a misjudged click is worse than not supporting precise click-to-row at all. What's shipped, the reliable subset: - Wheel scroll everywhere there's something to scroll: tables via the already-exported MoveUp/MoveDown (no scroll-state assumptions needed), viewports via their own native wheel handling (bubbles/ viewport already has this - nothing in the codebase was routing tea.MouseMsg to it yet), and vi-modal text editors via new viTextarea.ScrollUp/ScrollDown (bubbles/textarea has zero native mouse handling at all, confirmed the same way - feeds wheel events as repeated up/down keypresses through the same tested movement path h/j/k/l already use). - Right-click opens a context menu (cmd/mitmux/contextmenu.go) - a horizontal strip taking over the status/help line, the same "replace the bottom of the screen" pattern confirmPrompt and the export/import prompts already use, rather than a floating popup positioned at the click (lipgloss/bubbletea have no compositor for splicing an overlay into an arbitrary screen position - not worth building just for this). Wired into every list-based view: history (view/repeater/intruder/flag-unflag/delete), rules (edit/enable-disable/delete), scope (enable-disable/delete). Menu items ARE reliably clickable, unlike table rows - the menu renders its own strip, so every item's width is fully known rather than hidden behind a library's unexported scroll state. Navigable by mouse click or j/k/arrows+enter; esc or right-clicking again dismisses. Deferred, not silently dropped: click-to-select-a-different-row (same scroll-offset limitation), and click-to-switch-pane-focus in Repeater/ Intruder (tractable via the same Y-coordinate math WindowSizeMsg already computes, just not done yet - keyboard tab already covers it, so lower priority than what shipped). Verified live in tmux by injecting real SGR mouse escape sequences directly into the pane (tmux send-keys -l with hand-built ESC [ < Cb;Cx;Cy M/m sequences, since tmux has no built-in "synthesize a click" primitive) against a running daemon with real captured entries: wheel-down/up on the history table correctly moved the selected-row highlight (confirmed via ANSI-aware capture, not just "no crash"); right-click opened the menu with the right actions; clicking directly on a computed menu-item position correctly triggered that exact action (clicked "delete", saw the correct entry's ID in the resulting confirm prompt); keyboard navigation inside the menu moved the highlight correctly; esc and a second right-click both dismissed cleanly with no side effects; wheel events in Repeater's text pane and Detail's viewport caused no crash and left vi-mode state intact; an empty rules table's right-click correctly no-opped; adding a real rule then right-clicking and clicking "disable" correctly toggled it off (confirmed via the rendered checkmark disappearing). go build/vet/gofmt/test/mod tidy all clean. --- README.md | 43 +++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 43 insertions(+) (limited to 'README.md') diff --git a/README.md b/README.md index dfa9f87..13e9429 100644 --- a/README.md +++ b/README.md @@ -66,6 +66,10 @@ list of what's deliberately not implemented (and why), see read-only response views), standard vi navigation (`j`/`k`, `g`/`G`, `ctrl+u`/`ctrl+d`) already works - that's the underlying TUI library's default, not something layered on top. +- **Mouse support**: wheel scroll anywhere there's something to + scroll, right-click for a context menu on the history/rules/scope + lists. Coexists with tmux's own mouse mode the same way any other + mouse-aware terminal app does. See [Mouse](#mouse) below. ## Install / build @@ -225,6 +229,9 @@ below is enough to get going. | `s` | target scope (what gets recorded) | | `q` | quit | +Also mouse-driven - wheel to scroll, right-click a row for a context +menu of the same actions. See [Mouse](#mouse) below. + ### Detail view `tab` switches request/response, `p` toggles pretty-printed JSON on the @@ -417,6 +424,42 @@ Repeater and Intruder always record regardless of scope - a request you deliberately resend or fuzz is something you clearly want to see the result of, not noise scope exists to cut. +### Mouse + +This is a real terminal application (any terminal, not just tmux - the +name is a naming convention, not a runtime dependency) with genuine +mouse support, not just a keyboard-only TUI: + +- **Wheel** scrolls whatever's focused - the history/rules/scope + tables, a Detail/Comparer/Decoder-output pane, or a Repeater/ + Intruder text editor. +- **Right-click** a row in the history, rules, or scope list opens a + context menu of the same actions the keyboard shortcuts already do + (view/repeater/intruder/flag/delete for history, edit/enable-disable/ + delete for rules and scope). Click an item, or navigate with + `j`/`k`/arrows and `enter`; `esc` or right-clicking again dismisses + it without doing anything. + +One honest limitation, not an oversight: the menu always acts on the +row that's currently *selected*, not necessarily the exact row your +cursor happens to be over when you right-click. The underlying table +widget doesn't expose its own scroll position, so there's no reliable +way to map a click's screen coordinates back to a specific row without +reaching into that library's private internals - which this +deliberately doesn't do, rather than risk silently selecting the wrong +one. Scroll or navigate to the row you want first; wheel scroll and +keyboard navigation both work exactly as you'd expect. + +If you're running inside tmux, its own mouse mode needs to be on too +(`set -g mouse on` in `.tmux.conf`) for mouse events to reach mitmux at +all - tmux forwards them to whichever pane is focused once that's set, +the same way it does for nvim or any other mouse-aware terminal app, +nothing mitmux-specific to configure. If you ever want to select and +copy on-screen text with the mouse instead (which an app with mouse +mode on normally intercepts), most terminal emulators let you hold +Shift while click-dragging to fall back to the terminal's own native +selection. + ## Architecture `mitmuxd` owns the proxy listener and the SQLite database; `mitmux` is -- cgit v1.2.3