-
Notifications
You must be signed in to change notification settings - Fork 8.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bug Report: if historySize >= 32728 a maximize doesn't redraw the terminal #2815
Comments
Well, that's a thinker. |
Pretty much everything in the terminal implementation is a short, and while the initial history size is clamped, that's not enough to prevent an overflow when values are added. In this particular case, I believe the overflow is happening here:
Clamping that result to SHORT_MAX seems to fix the issue, but I wouldn't want to bet on that being the only place that needs clamping. Conhost avoids the issue by limiting the scrollback to 9999, which seems like a safer approach. |
Welp, that's certainly my fault there. That's definitely wrong there, good find. I think we should definitely make sure to use this issue as a chance to go through and audit some of our math in the Terminal code and make sure we're safemathing/clamping it. I clearly didn't do that originally, and we should be. IIRC technically only the propsheet limits you to 9999 rows for conhost. I believe if you edit the registry directly, you can sidestep that to get to SHORT_MAX. |
Yeah, you're right. But that means conhost likely has many issues like this too, and I suspect it's going to be a nightmare to audit. Just look at Personally I'd just clamp the initial buffer size to something like 30000, if that meant we could avoid having to deal with all those edge cases. |
## Summary of the Pull Request This is 100% on me. Even after mucking around in this function for the last 3 months, I missed that there was a single addition where we weren't doing a clamped addition. This would lead to us creating a buffer with negative height, and all sorts of badness. Clamping this addition was enoguh to fix the bug. ## PR Checklist * [x] Closes #2815 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed * ran tests * Created a profile with `"historySize" : 32728`, then filled the viewport with text, then maximized, and saw that the viewport indeed did resize to the new size of the window.
## Summary of the Pull Request This is 100% on me. Even after mucking around in this function for the last 3 months, I missed that there was a single addition where we weren't doing a clamped addition. This would lead to us creating a buffer with negative height, and all sorts of badness. Clamping this addition was enough to fix the bug. ## PR Checklist * [x] Closes #2815 * [x] Closes #4972 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed * ran tests * Created a profile with `"historySize" : 32728`, then filled the viewport with text, then maximized, and saw that the viewport indeed did resize to the new size of the window.
## Summary of the Pull Request This is 100% on me. Even after mucking around in this function for the last 3 months, I missed that there was a single addition where we weren't doing a clamped addition. This would lead to us creating a buffer with negative height, and all sorts of badness. Clamping this addition was enough to fix the bug. ## PR Checklist * [x] Closes #2815 * [x] Closes #4972 * [x] I work here * [x] Tests added/passed * [n/a] Requires documentation to be updated ## Validation Steps Performed * ran tests * Created a profile with `"historySize" : 32728`, then filled the viewport with text, then maximized, and saw that the viewport indeed did resize to the new size of the window. (cherry picked from commit f221cd2)
🎉This issue was addressed in #4964, which has now been successfully released as Handy links: |
Environment
Steps to reproduce
nano
on Ubuntu is easier).Expected behavior
The terminal should redraw itself to occupy all the available space.
Actual behavior
The terminal keeps using the previously available space, not occupying the extra one. Some screenshots:
After maximizing on Ubuntu:
After maximizing on cmd:
(Note the last
dir
output kept going but it was cut midway)Other relevant information
A manual resize of the window does correctly trigger a redraw on Ubuntu. Not on cmd, which just keeps using the window space it had when the tab was opened.
The text was updated successfully, but these errors were encountered: