0.8.2 local attach: DECRQM answers ?1016 SET but mouse reports stay cell-coordinate (terminal-browser clicks land top-left)

[stephanschubert]

Is this a reproducible bug?

• I confirm this is a reproducible bug, not a feature request, idea, question, contribution proposal, or direction check.
• I reproduced this bug on the version and environment reported below using the exact steps provided.

Current behavior

Mouse input does not reach terminal-browser running in a Herdr pane on 0.8.2, on a local direct attach (no SSH, no tmux). The page renders correctly and keyboard input works, but no click has any effect.

This is the same symptom as #2673, which was closed on 2026-08-11 as fixed by #2523 ("negotiated exact pixel mouse input") and shipped in 0.8.2. It is not #3074 either: that one is about SSH/tmux clients being denied pixel_mouse, whereas here pixel_mouse is advertised as true.

What I measured:

1. pane.graphics.info for the browser pane, and for every other pane in the session, reports the same values. pixel_mouse is on:

{"type":"pane_graphics_info","cell_width_px":14,"cell_height_px":27,
 "pane_visible":false,"file_frame_damage":true,"max_layers_per_pane":16,
 "pixel_mouse":true}

cell_height_px: 27 is exact — the pane is 64 rows over 1728 device pixels — so this is not a cell-metrics problem.

2. Doing what terminal-browser does (enable 1000/1002/1006/1016, then query DECRQM CSI ? 1016 $ p), Herdr answers ?1016;1$y = SET. The reply is also slow: a 1.5s read window missed it and the following query picked it up.

3. With 1016 enabled and reported SET, the SGR reports that arrive are still cell sized. A small A/B in one clicking session, plain 1006 first and then 1006+1016:

PHASE A (1006 only):  max x=16 y=22  -> cell sized
PHASE B (1006+1016):  max x=14 y=37  -> cell sized

The pane was ~113 columns by 66 rows and about 1554x1728 device pixels. As pixels those coordinates would put both clicks within ~2% of the top-left corner; as cells they land mid-pane, which is where the clicks were.

Consequence for any client that trusts the DECRQM answer: it is told pixel mode is on, receives cell numbers, and maps every click into a tiny patch at the top-left of the page. Clicks are not dropped, they all land in the same wrong place.

Expected behavior

Either of these would be consistent, the current combination is not:

• If Herdr answers DECRQM ?1016 with SET and advertises pixel_mouse: true, mouse reports forwarded to the pane should carry pixel coordinates.
• If Herdr forwards cell coordinates, DECRQM ?1016 should answer RESET and pixel_mouse should be false, so the client uses its cell-coordinate fallback (which feat(graphics): add direct pane frame streaming #2523's tests cover).

Reproduction

1. Herdr 0.8.2, local attach, Ghostty, [experimental] kitty_graphics = true, [ui] mouse_capture at its default.
2. terminal-browser open --split right https://example.com in a pane (0.6.0).
3. Click links in the browser pane. Nothing responds; keyboard works.
4. In any pane, enable mouse tracking including 1016, query printf '\e[?1016$p', and observe the SET reply. Then capture the raw SGR reports and compare their magnitude against the pane's pixel size.

Impact

terminal-browser is unusable with the mouse inside Herdr. This is the same user-visible breakage as #2673, which is closed.

Caveat on evidence: point 3 rests on a small number of clicks (one per phase), because I could only measure through a person clicking. Points 1 and 2 are deterministic and repeatable without any mouse input, and on their own they show DECRQM answering SET.

Environment

• Herdr: 0.8.2
• terminal-browser: 0.6.0
• Host terminal: Ghostty 1.3.2-main-+65744ffe3
• OS: macOS (Darwin 25.5.0), Apple Silicon
• Shell: zsh
• Attach: local, direct (no SSH_CONNECTION, no TMUX)
• [ui].mouse_capture: default (true)
• [experimental].kitty_graphics = true

[JJLiebig]

@akbash-bot this issue predates #3487. Local launches now use the client-rendered shell, and the current client attach path preserves pixel reports and sends semantic pixel mouse events instead of relying on the old direct-attach behavior. Please re-test terminal-browser clicks on current master and close or update the issue from that result.

[akbash-bot]

Retested current master (8633a398) with terminal-browser 0.7.6 in a disposable client-rendered Linux/Xvfb session. With pixel mouse enabled and exact host geometry, raw SGR 1016 input was forwarded as pane-local pixel coordinates (for example, host 604,283 became pane 140,251), and a click aimed at “Learn more” navigated from example.com to iana.org.

This confirms that the stale direct-attach failure is gone after #3487. Closing as fixed on master.

[SLatz18]

Retested on current master as requested. The ordinary nested child-PTY path still fails; this looks distinct from the terminal-browser retest that closed the issue.

Master build

• Repo: herdrdev/herdr
• Commit: 6045fe6a8735609507ec8600fa07205227546e8b
• Host: Linux x86_64, Ghostty 1.3.1
• Attach: local (no SSH, no tmux)
• Binary: release build of that commit

Gap vs the closing retest

Closing retest: terminal-browser with host events that were already pixel-positioned (example cited: host 604,283 → pane 140,251).

This check: ordinary child PTY after Bubble Tea-style enable: CSI ?1006h, then CSI ?1016h, then CSI ?1006h again. Mode 1016 remains SET. The bytes written into the child are still cell-sized.

Measured encode on that master commit

Pane terminal: 80×24 cells, 10×20 cell pixels. After the enable sequence above, encoding a left-click at pane-local pixels (x=403, y=240) produced:

\x1b[<0;41;13M

Observed: x=41 (cell-scale).
Expected for SGR-Pixels at that click: x=403 (pixel magnitude).

So a mid-line click in a nested Bubble Tea / click-to-caret TUI still lands near the left / column 1 on current master.

Live probe (copy-paste into a pane on that master binary)

#!/usr/bin/env python3
"""Minimal nested-PTY 1016 probe: enable mouse, print raw SGR reports + DECRQM."""
import os, sys, termios, tty, select

def enable():
    # tracking + SGR + SGR-Pixels (Bubble Tea style: 1006 then 1016 then 1006 again)
    sys.stdout.write("\x1b[?1000h\x1b[?1003h\x1b[?1006h\x1b[?1016h\x1b[?1006h")
    sys.stdout.write("\x1b[?1016$p")  # DECRQM 1016
    sys.stdout.flush()

def disable():
    sys.stdout.write("\x1b[?1000l\x1b[?1003l\x1b[?1006l\x1b[?1016l")
    sys.stdout.flush()

def main():
    cols = os.get_terminal_size().columns
    rows = os.get_terminal_size().lines
    print(f"probe cols={cols} rows={rows}", flush=True)
    print("click around mid-line; Ctrl-C to quit", flush=True)
    fd = sys.stdin.fileno()
    old = termios.tcgetattr(fd)
    try:
        tty.setraw(fd)
        enable()
        buf = b""
        while True:
            r, _, _ = select.select([fd], [], [], 0.2)
            if not r:
                continue
            chunk = os.read(fd, 4096)
            if not chunk:
                break
            if b"\x03" in chunk:  # Ctrl-C
                break
            buf += chunk
            while True:
                i = buf.find(b"\x1b[<")
                if i < 0:
                    # DECRQM reply CSI ? 1016 ; Ps $ y
                    j = buf.find(b"\x1b[?")
                    if j >= 0 and b"$y" in buf[j:]:
                        end = buf.find(b"$y", j) + 2
                        sys.stdout.write(f"DECRQM: {buf[j:end]!r}\r\n")
                        sys.stdout.flush()
                        buf = buf[end:]
                        continue
                    break
                end = -1
                for k in range(i + 3, len(buf)):
                    if buf[k] in b"Mm":
                        end = k + 1
                        break
                if end < 0:
                    break
                report = buf[i:end]
                buf = buf[end:]
                # parse x;y from \x1b[<b;x;yM
                try:
                    body = report[3:-1].decode()
                    _b, x, y = body.split(";")
                    x, y = int(x), int(y)
                    kind = "pixel-ish" if x > cols or y > rows else "cell-sized"
                    sys.stdout.write(f"SGR x={x} y={y} ({kind}) raw={report!r}\r\n")
                    sys.stdout.flush()
                except Exception:
                    sys.stdout.write(f"SGR raw={report!r}\r\n")
                    sys.stdout.flush()
    finally:
        disable()
        termios.tcsetattr(fd, termios.TCSADRAIN, old)
        print("\ndone", flush=True)

if __name__ == "__main__":
    main()

Mid-pane clicks print SGR x=… (cell-sized) while DECRQM shows 1016 SET. Same script directly in Ghostty (no Herdr) prints (pixel-ish) with x ≫ columns.

I can add a live Ghostty→Herdr transcript from this master binary if you want that form instead of the encode measurement.

cc @Pimpmuckl @akbash-bot

[SLatz18]

Follow-up: live Ghostty → master 6045fe6 → ordinary child PTY probe (not terminal-browser).

• Command: release binary --session master-1016-probe
• Probe cols=100 rows=32
• DECRQM: \x1b[?1016;1$y (1016 SET)
• Mid-pane clicks into the child:

SGR x=44 y=16 (cell-sized) raw=\x1b[<35;44;16M
SGR x=44 y=16 (cell-sized) raw=\x1b[<0;44;16M
SGR x=54 y=19 (cell-sized) raw=\x1b[<35;54;19M
SGR x=54 y=19 (cell-sized) raw=\x1b[<0;54;19M
SGR x=34 y=14 (cell-sized) raw=\x1b[<35;34;14M
SGR x=34 y=14 (cell-sized) raw=\x1b[<0;34;14M

All mid-pane clicks stayed cell-sized (x ≤ columns). Matches the encode measurement above.

cc @Pimpmuckl @akbash-bot

[JJLiebig]

@akbash-bot can you check the follow up comments #3295 (comment) and #3295 (comment)

[JJLiebig]

@SLatz18 thank you for the excellent repro steps!