Exception when switching buffer after resize

[mofux]

Problem

An exception is thrown (latest master and probably before) if we resize the screen to a bigger dimension while being in the alt screen buffer. Once the alt screen buffer exists and we switch back to the normal buffer, the exception will show up, and the terminal will stop working (blank screen).

I think this has the same root cause as #838 and likely others where the line or row data is an undefined reference.

How to reproduce

• Start the demo
• Run a command that uses the alt screen buffer (e.g. vim)
• Change the rows and/or cols value to a higher value (it happens in both cases)
• Exit the app to switch back to the normal buffer

Demo

[mofux]

Obviously this happens because the renderer assumes that the dimensions of the normal buffer is in sync with the rows / cols, but it isn't. I think we have to adjust the size of a buffer to the current dimensions when activating it -- and before the renderer touches it.

[Tyriar]

Can reproduce with vim and 40x40

[Tyriar]

It appears to only happen when the normal buffer isn't filled.

[Tyriar]

Yeah it's related to not filling in the normal buffer's rows when the rows increase. Can reproduce with vim and rows+1.

[Tyriar]

Related to #510. I think when BufferSet was added, checks were removed so we no longer clear the normal buffer when resizing in the alt buffer. Apparently we missed this one case.

[Tyriar]

Here's the line that prevented this: https://github.com/sourcelair/xterm.js/pull/717/files#diff-d4f745d6f29faa0617f2e02bb95f0c44L2039

[Tyriar]

The same also breaks when rows change in the other direction, the scrollbar shows there is more content but you can't scroll it (because they're blank lines).

[Tyriar]

Obscure bug I ran into while coming up for a fix here. after activateAltBuffer if called, there is a hard reset on the terminal which tries to carry buffers over but it's initialized and buffer (the convenience var) is set to the active buffer that we create and discard.

[mofux]

You're a genius, thanks @Tyriar!

[ZoeyR]

Hey, I just thought I'd report that I'm still having this issue with the 2.9.1 release of xtermjs. Right after I call term.open(...) I call term.fit() and I get the same exception. It's not 100% consistent but it happens frequently enough to be an issue. 2.8.1 does not have this problem for me.

[parisk]

@dgriffen is there any chance that what you are reporting is this: #860?