Resize/reflow broken

Resize is pretty broken, as it doesn’t properly wrap text. This is making it difficult to create split panes which are resized often. I’ve tested this behavior in VSCode and it appears to be an issue there as well. I suspect this may be an inherit problem with the renderer/pty coordination, as I also see this issue (mildly) in both iTerm and the native MacOS terminal.

Details

• Browser and browser version: Electron 8.0.1
• OS version: MacOS Mojave 10.14.6
• xterm.js version: 4.4.0

Steps to reproduce

1. Create xterm window hooked up to pty (https://github.com/microsoft/node-pty/tree/master/examples/electron).
2. Use a resizeObserver on the top-level container that calls fitAddon.fit(), then propagates the rows/cols to pty.
3. Rapidly resize the window.

I’ve tried debouncing the resize calls, but this doesn’t help.

[gfadlallah]

@jerch Fair enough, thanks for explaining a possible solution. Will try to work around this by simply debouncing the pty resize and creating a UX that mitigates this behavior.

Closing this now, but submitting another sizing bug that I think is unrelated to this behavior.

[jerch]

@gfadlallah Yepp, this summarizes the problem behind the curtain.

My question is: why can’t xterm resize the cursor lines itself? If, hypothetically speaking, we had a way to systematically ignore data that came from pty as a result of a resize, then we could just resize pty in the background while xterm handled all the resize logic for all the text.

This wont work either, as we dont know whether the next chunks are a result of SIGWINCH, where the app tries to “repair” the screen state.

Only chance I see is to do the full roundtrip and drain buffers in between:

• terminal gets resized
• pause pty
• drain all buffers
• call pty.resize
  • triggers SIGWINCH
  • app might want to refresh screen state, but pty is still paused (writes are blocking)
• on SIGWINCH
  • do the actual resize in terminal with reflowing
  • resume pty
• next chunks are most likely meant for the new geometry (minus prebuffered data on pty slave, that was written right before pty pause)

This should lower the chance of the race condition by far. Downside of this solution is the implementation overhead (needs several server side adjustments, that are beyond xterm.js control) and the full stop on all interfaces.