After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 772124 - wget progress bar getting corrupted when resizing the window
wget progress bar getting corrupted when resizing the window
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
git master
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2016-09-28 14:04 UTC by Igor
Modified: 2021-06-10 15:16 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
vte_wget_progress_bar.png (78.37 KB, image/png)
2016-09-28 14:04 UTC, Igor
Details

Description Igor 2016-09-28 14:04:46 UTC
Created attachment 336447 [details]
vte_wget_progress_bar.png

Resizing (shrinking, in particular) the terminal window makes wget progress bar corrupted: please see the attachment.
xterm, on the other hand, manages to handle resizes in a way that the progress bar becomes shorter or longer and doesn't get corrupted.
Thanks.
Comment 1 Egmont Koblinger 2016-09-28 15:34:35 UTC
I think this is pretty much inevitable if you have rewrap on resize: The terminal rewraps its contents, the progress bar gets wrapped into two lines, and the app (unaware of this) refreshes the last line.

Could you please check if the bug still occurs if you disable rewrap on resize? There's a VTE API call for that, or a checkbox in gnome-terminal's profile prefs.
Comment 2 Igor 2016-09-28 15:46:54 UTC
I've disabled rewrap on resize in gnome-terminal and the bug is still there. It's not as much and as harmful as with rewrap enabled, but the progress bar is still messed up, especially when resizing the window many times.
Comment 3 Egmont Koblinger 2016-09-28 15:49:37 UTC
Thx; I'll take a closer look as time permits.
Comment 4 Egmont Koblinger 2016-09-28 19:43:55 UTC
(Still haven't looked at it.)

There is an inherent race condition even without rewrapping. The terminal emulator and the app inside (wget in this case) run asynchronously in parallel. It is always possible that the app outputs something in the belief that the width is w1 whereas the actual width is already w2 (the app is just about to get notified).

If w2 < w1 then this can easily cause a wrap of the progress bar which won't be repaired upon the app repainting the last line.

The proper solution is either not to have such progress bar :P, or to have an app that controls the entire screen (such as typical ncurses apps). Those may still temporarily print something assuming the width is w1 whereas it's already w2 and hence it shows up garbled on the screen, but it will immediately be followed by a full repaint with the correct new width.

It could be that, due to whatever reason, this race condition is hit more frequently in g-t than in xterm.

Or, of course, could be an actual bug...
Comment 5 Igor 2016-09-29 10:46:15 UTC
Actually, you are right: I can make xterm mess up the progress bar output if I resize the window back and force continuously and fast. But it's indeed happening more frequently in g-t.
Comment 6 GNOME Infrastructure Team 2021-06-10 15:16:30 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2345.