Code change:
The <kbdToggle Size to Content Width</kbdcan only be toggled a few times, before freezing completely. Resizing terminal could reset it. https://user- Does this issue occur when all extensions are disabled?: Yes System info:
please see my explanation on
Thank you for your detailed explanation. I did test on the insider version, the blur seems to decreased with smaller canvas required but this freezing issue still happens all the time. Moreover, the issue is only on Linux so I'm not sure the explanation is quite sufficient to describe this. Let me know if there's anything I missed, thanks again.
when you do this how long as the lines you're working with? ideally, we probably need an upper cap based on the environment's max canvas size (which would need some searching).
It's hard to say when the doesn't work as expected this time. Do you have any idea to get this revealed? https://user-
when the width of the longest line is less than the width of the terminal, as is featured in your gif, toggling the width won't do anything (by design).
thanks for your information, I did some tests again and got some conclusions: in the menu doesn't work, so I recorded with shortcut . IIt also freezes after the second as expected (bottom scrollbar indicates that): https://user- lines hidden when press are affected (still freezes after the second toggle): https://user- number 2 above seems to happen almost every line length: ! Let me know if I can do any more tests to provide more information.
As compared with how this works for windows/mac, linux is broken given the same text content !
This actually is working by design - when you copy and paste, it includes newline line endings that will indicate to the terminal that line isn't wrapped.
based on , it seems like we should go with the min value since we don't want to calculate this per platform/browser, so going with 8000
I started on Windows to try to understand how works. It didn't appear to do anything on Windows. On linux, I can see the toggle happen, but there is no scroll bar.
it will only happen if there are wrapped lines. so increase the line width or resize the terminal to be more narrow.
the scrollbar is very low on linux and i'm not sure why. I'll open an issue for that - separate from this one
Windows !
thanks, i'll make a new issue for that
Now the same thing is happening on linux too. I will leave this for someone else to verify.
Thank you for getting back. I've tested with the insider build but it doesn't work, I've thought it was some sort of thing related to my particular machine, which confuses me these days. So it's good to track that again on a new issue. Most of behavior I have described in I don't spend much time on Windows so didn't test carefully. Let me know if there's anything else I can do.
Because of the way this feature works where it stretches the canvas to the size of the content we are limited by the canvas API. As a compromise I'm going to add a cap to the number of columns the terminal can take up.

Related discussion:
text: this._initDimensions(); await this._resize(); } else { <ins> const font = this.xterm ? this.xterm.getFont() : this._configHelper.getFont(dom.getWindow(this.domElement)); const maxColsForTexture = Math.floor(Constants.MaxCanvasWidth / (font.charWidth ?? 20)); </ins> // Fixed columns should be at least xterm.js' regular column count <del> const proposedCols = Math.max(this.maxCols, Math.min(this.xterm.getLongestViewportWrappedLineLength(), Constants.MaxSupportedCols)); </del> <ins> const proposedCols = Math.max(this.maxCols, Math.min(this.xterm.getLongestViewportWrappedLineLength(), maxColsForTexture)); </ins> // Don't switch to fixed dimensions if the content already fits as it makes the scroll // bar look bad being off the edge if (proposedCols > this.xterm.raw.cols) {