Ticket #4019 (closed defect: fixed)
regression: resize/resizing window while command is executing is impartially felt by mc
Reported by: | howaboutsynergy | Owned by: | andrew_b |
---|---|---|---|
Priority: | minor | Milestone: | 4.8.24 |
Component: | mc-tty | Version: | master |
Keywords: | window, resize | Cc: | |
Blocked By: | Blocking: | ||
Branch state: | merged | Votes for changeset: | committed-master |
Description
What steps will reproduce the problem?
- start 'mc' within an xfce4-terminal window
- run this command in 'mc':
read -rp "press enter after resizing xfce4-terminal window"
- resize the window by making it larger in both X and Y directions
- press Enter to the prompt in 2.
- press Enter if prompted by 'mc' to "Press any key to continue..." to return to 'mc' panels
What is the expected output?
the panels are resized to the new window size
What do you see instead?
the panels are the same size as before the command in 2. got executed, but the lower bar (with the F1-F10 keys info) is resized correctly in the X direction.
(screenshots will be attached)
$ LC_MESSAGES=C mc -V GNU Midnight Commander 4.8.23-75-g0ef1737aa Built with GLib 2.62.0 Using the S-Lang library with terminfo database With builtin Editor With subshell support as default With support for background operations With mouse support on xterm With internationalization support With multiple codepages support Virtual File Systems: cpiofs, tarfs, sfs, extfs, ftpfs, sftpfs, fish Data types: char: 8; int: 32; long: 64; void *: 64; size_t: 64; off_t: 64; $ LC_MESSAGES=C mc -F Home directory: /home/user Profile root directory: /home/user [System data] Config directory: /etc/mc/ Data directory: /usr/share/mc/ File extension handlers: /usr/lib/mc/ext.d/ VFS plugins and scripts: /usr/lib/mc/ extfs.d: /usr/lib/mc/extfs.d/ fish: /usr/lib/mc/fish/ [User data] Config directory: /home/user/.config/mc/ Data directory: /home/user/.local/share/mc/ skins: /home/user/.local/share/mc/skins/ extfs.d: /home/user/.local/share/mc/extfs.d/ fish: /home/user/.local/share/mc/fish/ mcedit macros: /home/user/.local/share/mc/mc.macros mcedit external macros: /home/user/.local/share/mc/mcedit/macros.d/macro.* Cache directory: /home/user/.cache/mc/ $ mc --configure-options '--prefix=/usr' '--sysconfdir=/etc' '--libexecdir=/usr/lib' '--enable-background' '--enable-network' '--enable-netcode' '--enable-charset' '--enable-nls' '--with-vfs' '--with-edit' '--with-screen=slang' '--without-x' '--without-samba' '--without-gpm-mouse' '--without-gnome' '--without-debug' '--without-included-gettext' '--disable-dependency-tracking' '--enable-tests'
Attachments
Change History
Changed 5 years ago by howaboutsynergy
- Attachment before_Screenshot_2019-09-19_17-14-50.png added
Changed 5 years ago by howaboutsynergy
- Attachment middle_Screenshot_2019-09-19_17-15-08.png added
step 2&3 aka middle
Changed 5 years ago by howaboutsynergy
- Attachment after_Screenshot_2019-09-19_17-15-22.png added
after step 5
comment:1 Changed 5 years ago by andrew_b
The regression was introduced in [37ffc024225fd2ef1016babf3cbbeabce4a32899].
comment:2 Changed 5 years ago by andrew_b
Before [37ffc024225fd2ef1016babf3cbbeabce4a32899] we had mc_global.tty.winch_flag that was set in sigwinch_handler(), than it checked some times (note: checked but no reset) and finally reset in dialog_change_screen_size().
Currently we have tty_got_winch() function that checks whether SIGWINCH was raised. But this function has side effect: the virtual SIGWINCH flag is reset after read. 'Virtual flag' means the non-emptiness of FIFO. If tty_got_winch() is sequentially called several times, only first call can return TRUE (FIFO was not empty at this moment), other calls return FALSE (read from an empty FIFO). Finally, dialog_change_screen_size() may not be called in dialog event loop in frontend_dlg_run(). Such case we have if SIGWINCH is raised while subshell is active.
I've tried fix that in
branch: 4019_resize_fix
changeset:4c36a5c8ea3386fbdf6b911986092fac11a0508a
But I'm afraid it is overcomplicated compared to using a simple variable before [37ffc024225fd2ef1016babf3cbbeabce4a32899].
comment:3 follow-up: ↓ 4 Changed 5 years ago by ossi
can't resist placing a big fat "told you so" here. :P
did something go wrong while committing the fix? what i see on trac cannot possibly be complete (two one-liners in two files, and it doesn't match the commit message).
comment:5 follow-up: ↓ 6 Changed 5 years ago by ossi
ok, patch doesn't look bad (disclaimer: i did not examine the whole context the code lives in). some observations:
- typo in commit message: "check whether it [i]s empty"
- comment says "no timeout", but you actually mean "instant timeout" (or "don't block")
- the original code had a second flush around line 530 in execute.c. that whole hack *might* be obsolete now, but that needs investigation.
comment:6 in reply to: ↑ 5 Changed 5 years ago by andrew_b
Replying to ossi:
- typo in commit message: "check whether it [i]s empty"
Commit message will be fixed before merge.
- comment says "no timeout", but you actually mean "instant timeout" (or "don't block")
Fixed
- the original code had a second flush around line 530 in execute.c. that whole hack *might* be obsolete now, but that needs investigation.
Restored.
comment:7 Changed 5 years ago by howaboutsynergy
I tried this https://github.com/MidnightCommander/mc/compare/4019_resize_fix.patch on top of 4.8.23.82.gb633256c7-1 and it works! Thank you.
comment:9 Changed 5 years ago by andrew_b
- Votes for changeset changed from howaboutsynergy to howaboutsynergy andrew_b
- Branch state changed from no branch to approved
- Milestone changed from Future Releases to 4.8.24
comment:10 Changed 5 years ago by andrew_b
- Status changed from new to closed
- Votes for changeset changed from howaboutsynergy andrew_b to committed-master
- Resolution set to fixed
- Branch state changed from approved to merged
Merged to master: [2cf2a183ec24a2b6fc769a9abfefadfc2bdabf59].
comment:11 Changed 5 years ago by andrew_b
- Status changed from closed to reopened
- Resolution fixed deleted
comment:12 Changed 5 years ago by andrew_b
- Owner set to andrew_b
- Status changed from reopened to accepted
comment:13 Changed 5 years ago by andrew_b
- Status changed from accepted to testing
- Resolution set to fixed
step1 aka before