xterm-addon-serialize taint the background of next line when line wrap + scroll happen

[mmis1000]

Details

• Browser and browser version:
• OS version:
• xterm.js version:

Steps to reproduce

1. press enter several times until scrollbar appear
2. run echo -e "\x1b[44m\x1b[86X\x1b[87C1\x1b[m\r\n\r\n"
3. check the Write back to terminal option of SerializeAddon
4. click Serialize the content of terminal
5. Notice the background of next line is tainted

Note

It seems this can't be solved without insert \x1b[m at line end when the last cell has background.
But do this will break all current tests?

Or you need to do a costly look ahead to next line to check whether a reset is required or not.

[jerch]

Imho the serializer tests only for null content atm (and tries to be smart about nullish cells), what is missing here is the text attributes check for every cell, that would have to be recorded as well. Imho the issue would vanish, if the serializer does likewise here - use ECH + some cursor repositioning to correctly update attribs for nullish cells.

Note that you have to use ECH + cursor repositioning, as directly writing of '\x00' would be swallowed as padding by the parser and not write null cells or advance the cursor.

About adding a line delimiting style directive:
Imho the easiest way is always to start at a new line with SGR 0 ; <other attribs>.

[mmis1000]

SGR 0 at next line start probably does not work.
Because the whole line already inherited the background of current cursor style during scroll and insert newline.
Reset the cursor style after scroll won't clear the background.

SGR 0; EL; SGR <other attribs> probably work, but there is no guarantee that there is still some lines after current line for you to insert EL without look ahead.

Scan the whole next line and check if there is any default background and insert SGR 0 at line end if there is any will probably give the most optimized result(the one most close to original input). But do this may be expensive or complicate, I am not sure whether it is worth to do that.

[jerch]

Getting cell styles should be possible as single pass, there is no need for costly look-ahead during serialize. Think of it like this:

• A scrolling row inherits the last active attrib set (BCE is set).
• Memoize the BCE attribs.
• Reset the new line with SGR0.
• Start plotting the cells with individual attribs from left to right, whenever a next cell has different attribs, insert the corresponding SGR sequence before writing its content.
• A null cell needs special treatment, as they are not directly printable. Use ECH + CUF instead. (If thats too complex to start with, maybe start with writing those cells with SP to fix visual output first, and do the real null stuff later on.)
• Null cells at the end of a line (the final not wrapping row), which share the same attribs, need just one ECH correction sequence to fix BG (minor optimization: If memoized BCE attribs hold same BG, this step and be skipped.)

Imho thats it basically, no need for complicated read-ahead BG evaluation. Note that the ECH + CUF patch for null cells above will not work correctly anymore, if the buffer content should be printed nicely on a terminal with different dimensions (as both sequences stop at the rightmost cell). I would ignore that in a first iteration, and see later, if this really should be addressed by the serializer. (There are several options to deal with that, from interim resizing to writing an active deserializer, which can request the dimensions of the target and alter the input accordingly.)

[mmis1000]

There is another problem for that.
BCE taint the background only when scroll happens.

That means the first Terminal.rows rows don't need to handle BCE because they wont' scroll.

So a conditional check need to be added to the serialize algorithm to prevent the first n rows from being messed up by non-exist BCE background.
And thus the output won't print nicely when dimension is different.

But that probably does not matter.
Because there seems actually some sequence that can't be achieved without manipulate cursor vertically.
Things like, there are two lines, second line is wrapped from first, but first line's last character is null.

[jerch]

BCE is basically not needed above in my list - it is just a minor optimization approach later on to get filling null cells to the right pretty quick. You can completely ignore it, and just go with the last found attrib BG data for filling null cells to the right. Yeah, Maybe its simpler to just ignore it during serialization.

Yes an early wrapping null cell between wide chars is a real bug in xterm.js as described in the other issue. Tthere is no way to decide on serializer level, whether its genuine data or just there from early wrapping.

[mmis1000]

This should have been fixed by #3101.

I forgot to tag this.
But it seems test is missing for this.
Probably need another test for confirming this actually works properly.