Bug 505217 - Resizing by ESC [ 8 ; <width> ; <height> t with larger width/height than fits has unexpected results
Summary: Resizing by ESC [ 8 ; <width> ; <height> t with larger width/height than fits...
Status: RESOLVED DUPLICATE of bug 238073
Alias: None
Product: konsole
Classification: Applications
Component: general (other bugs)
Version First Reported In: 25.04.1
Platform: Arch Linux Linux
: NOR normal
Target Milestone: ---
Assignee: Konsole Developer
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2025-06-04 18:43 UTC by julian
Modified: 2025-06-16 04:48 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description julian 2025-06-04 18:43:33 UTC
SUMMARY
Using the `ESC [ 8 ; <width> ; <height> t` escape sequence to resize the terminal will cause the cursor to be at a visually incorrect position if said width and height are larger than the current window size fits. The problem can be worked around by switching to another tab and back.

STEPS TO REPRODUCE
1. Open Konsole
2. Pick some width*height larger than the current window size, e.g. 80x80
3. Enter aforementioned escape sequence, e.g. echo -ne '\033[8;100;100t'
4. Scroll all the way down

OBSERVED RESULT
The cursor graphics moves away from where it was due to scrolling, and is at a vertical offset downwards from where the cursor really is. The screen also has more scrollable area to apparently match the size request, but I'm not sure whether or not this second point is intentional.

EXPECTED RESULT
The actual size would be clamped to what fits in the window and scrolling would not distort the cursor graphics' position.

SOFTWARE/OS VERSIONS
KDE Plasma Version: 6.3.5
KDE Frameworks Version: 6.14.0
Qt Version: 6.9.0

ADDITIONAL INFORMATION
Bug originally discovered due to a virtual machine printing an escape sequence that triggered it.
Using Arch Linux, Linux kernel currently 6.12.30-1-lts
Comment 1 John Kizer 2025-06-16 04:48:36 UTC
Merging in with an existing confirmed report for this issue, thanks!

*** This bug has been marked as a duplicate of bug 238073 ***