onScroll doesn't emit when user is scrolling

[schrej]

User scrolling is currently not emitted as an onScroll event. What's the reason for this? Is this really intended?
I'd like to monitor the scroll state of the terminal in order to notice when it's scrolled all the way down, so I have to notice when the user is scrolling, which is not possible with the current behavior.

Details

• Browser and browser version: Firefox 84.0.1
• xterm.js version: 4.9.0

Steps to reproduce

1. attach event listener with terminal.onScroll()
2. scroll the terminal using the mouse

[Tyriar]

Yes the onScroll API currently only fires when the terminal scrolled as a result of new data being written. I don't see any harm in making this change, it would need to go into a major version though as it's technically breaking.

[schrej]

Depending on how often you do major releases, or when you're planning to do the next one: it could be a config option to explicitly enable emitting those events, which would avoid the breaking change.
I'd be happy to PR whatever you prefer.

[jerch]

Not sure if we have a misconception here - onScroll currently mostly links to movements on the terminal ring buffer. Mostly here means, that the viewport is still linked to it somehow (disp?), but does not change anything on the ringbuffer itself, thus viewport scrolling without data changes is kinda expected not to fire onScroll.

We have interlinked two domains in onScroll - ringbuffer movements and viewport scrolling offset. Should we separate them into two events, maybe onScrollBuffer and onScrollViewport? Or is it safe to aggregate them further into just one event?

[Tyriar]

@schrej We do them pretty rarely, as we get the time to tackle a large portion of the assigned issues https://github.com/xtermjs/xterm.js/issues?q=is%3Aopen+is%3Aissue+milestone%3A5.0.0. I'd rather not add a new (deprecated) config option though.

@jerch I'm not sure if onScrollBuffer is useful, note also that technically the viewport doesn't scroll when scrollback is maxed out. The most useful/intuitive event imo is the union of the two, we could change that and then add an onScrollBuffer if there is unexpected demand for it?

[jerch]

@Tyriar Yupp sounds reasonable 👍 (also I dont see any use case for a "naked" buffer scroll event atm).

[schrej]

All right, guess I'll just have to wait for that release then.
I'll open a PR once I have time.

Any objections to adding a isAtBottom(): boolean method to check whether the terminal is scrolled all the way down as well? I'll do a separate PR for that of course.

[Tyriar]

Any objections to adding a isAtBottom(): boolean method to check whether the terminal is scrolled all the way down as well?

@schrej you can do this already by checking buffer.baseY === buffer.viewportY:

xterm.js/typings/xterm.d.ts

Lines 1253 to 1262 in 4de6f1c

	/**
	* The line within the buffer where the top of the viewport is.
	*/
	readonly viewportY: number;
	/**
	* The line within the buffer where the top of the bottom page is (when
	* fully scrolled down).
	*/
	readonly baseY: number;

[schrej]

Yeah, I found that out, just thought a method would make it easier for new people. But maybe there just aren't that many people with use cases similar to mine.

[daonb]

I need a onScrollBuffer, here's my use case.

I'm developing a touchable terminal multiplexer where the user can use the cut gesture to split the pane. My app can split both right-to-left and top-to-bottom. When a user scrolls fast the latter is firing unintentionally.

To solve this I added code to disable vertical splitting for 2 seconds after the user scrolls. I've tried using onScroll in my code as according to the docs it does just what I need:

Adds an event listener for when a scroll occurs. The event value is the new position of the viewport.

The event doesn't fire as expected and my panes keep splitting.