Unable to select text in pagination mode

[compnerd]

Windows Terminal version

1.22.10731.0

Windows build number

10.0.26100.0

Other Software

No response

Steps to reproduce

Using git log (which uses less as a pager as per default), I am unable to simply double click on the commit hash to select the text. Attempting to do so will result in re-rendering the entire terminal continuously for a while. I've noticed that ESC0D will sometimes appear in the bottom left corner, making me believe that this is a bug in the ANSI sequence parser. It seems that there would be something odd going on with the CSI interpreter, possibly mishandling the initial byte?

This seems to have triggered somewhat recently, though I cannot pin down whether it was a WT update or Patch Tuesday update.

The canary build seems to reproduce this as well.

Note that it helps to have a particularly large terminal (e.g. full screen).

Expected Behavior

No response

Actual Behavior

The terminal becomes non-responsive, redrawing the terminal.

[compnerd]

I suspect a related exhibition of the issue is that if you type a partial command on the terminal, and then attempt to highlight text, instead of highlighting the text, the cursor is moved to the beginning of the line.

[DHowett]

Hey @compnerd, nice to see you around these parts 🙂

Just a couple quick differential diagnostic questions...

• If you use Shift+click, are you able to select text again?
• Would you be able to grab a debug tap trace/?

I'm guessing that less enables a mouse mode (or requests a mouse mode) (or uses the Win32 console mode to request mouse mode and then enables VT input...) and doesn't know what to do with what it's getting back.

[compnerd]

Hey @compnerd, nice to see you around these parts 🙂

Hey @DHowett, great to see that you're still involved in Terminal! 😄

Just a couple quick differential diagnostic questions...

• If you use Shift+click, are you able to select text again?

I think that I didn't clearly explain the issue, sorry. It will let me select text again, just only after it has completed repainting the terminal a large number of times. You can identify this process as being complete because the terminal is fully rendered and scrolled up a line (which matches the CSI of 0D). But, just to verify, Shift+click doesn't select any text during the re-draw phase.

One thing that is interesting is that once this has occurred, it will function properly subsequently. So there is something more interesting going on, possibly with state initialisation?

• Would you be able to grab a debug tap trace/?

Well, the instructions seem complete enough, let me try to do that.

I'm guessing that less enables a mouse mode (or requests a mouse mode) (or uses the Win32 console mode to request mouse mode and then enables VT input...) and doesn't know what to do with what it's getting back.

Hmm, I didn't think of that. You think that this could be related to DECELR? That would allow it to read the scroll "button" (wheel) to allow pagination.

[compnerd]

• Would you be able to grab a debug tap trace/?

Well, the instructions seem complete enough, let me try to do that.

Well, that doesn't seem to work very well - it seems to truncate the buffer before I can get the interesting stuff due to the re-rendering.

[compnerd]

tap.txt

Okay, I used a different repository which doesn't have as big of a history, it actually is interesting as this is the second exhibition of the issue: it has already exited the pager (less). However, the text selection seems to still trigger the issue. I'm attaching the tap as an attachment here.

[compnerd]

It seems that yet another exhibition of this issue is if you scroll up, trying to highlight any text will scroll and then highlight, preventing copying any text on any row above the current viewport.