Scrollbar still visible after clearing screen and scrollback buffer with escape sequence

[SamVerschueren]

Details

• Browser and browser version: Google Chrome | 90.0.4430.93 (Official Build) (x86_64)
• OS version: macOS Big Sur
• xterm.js version: 4.9.0

Steps to reproduce

1. Use a regular terminal and execute ls -la a couple of times
2. Run printf '\u001B[2J\u001B[3J\u001B[H'
3. The screen is cleared and the scrollbar is removed because the scrollback buffer got cleared

Run the previous steps in xterm.js (easiest is probably VS Code). The screen gets cleared, the scrollback buffer gets cleared as well, but the scrollbar is still visible.

Here's a screen capture of that behaviour

More context on this can be found #3315 (comment)

[Puneethnaik]

Greetings @Tyriar . I would like to work on this issue. On preliminary analysis, i am able to trace till when the websocket 'message' event makes a call to terminal.write(). I need your advice on how to process the default prompt string as it can change from one OS to other and even with different bashrcs (on linux). Please guide me through the next steps.

[Tyriar]

@Puneethnaik I don't think the prompt format has anything to do with this issue. The scroll bar is managed by the viewport: https://github.com/xtermjs/xterm.js/blob/master/src/browser/Viewport.ts

[Puneethnaik]

@Tyriar my apologies 🙂 Thanks for directing me in the right direction. I will start studying Viewport.ts.

[jerch]

@Puneethnaik Viewport.ts might be misleading, I think it is much simpler - for some reason InputHandler.onScroll does not get respected in the renderer, while BufferService.onScroll does, prolly some missing link down the event routing. Also see #3315 (comment) for some background.

[Puneethnaik]

@jerch noted. Thanks for the hints. I will take all this into account and also check out the comment.

[Puneethnaik]

@Tyriar @jerch based on your valuable inputs, i have been studying the event listeners of _onScroll of bufferService, inputHandler. In CoreTerminal, there is a callback that fires the onScroll of CoreTerminal,when bufferService.onScroll event is fired. So in similar fashion, i included a callback that fires the onScroll of CoreTerminal, when inputHandler.onScroll event is fired.
The code that implements above logic is as follows:
this.register(this._inputHandler.onScroll(event => { this._onScroll.fire({ position: this._bufferService.buffer.ydisp, source: ScrollSource.TERMINAL }); this._dirtyRowService.markRangeDirty(this._bufferService.buffer.scrollTop, this._bufferService.buffer.scrollBottom); }));
This passes all the tests on running yarn test, and when i manually check the test given by SamVerschueren(Thanks Sam!), the behaviour is as expected. Am I heading in the right direction? Thanks in advance.

[jerch]

@Puneethnaik 👍 Yes, this sounds like the missing bit in the event propagation. Thanks for looking into it, for grabbing the events paths and locating the early cutoff of that event. Can only imagine how cumbersome it was to find it, events are somewhat hard to trace down due to their "cross-linking" nature.

[Puneethnaik]

Thanks a lot @jerch, i will create a PR for it then after following protocol. As you said, it was a bit tricky to find the event listeners as they are spread out among various objects. But, i was confident mainly because of the beautiful engineering that has gone into creating this wonderful product.