mirror of
https://git.tartarus.org/simon/putty.git
synced 2025-04-11 08:08:06 -05:00
fec6719a2b
A KDE user observed that if you 'dock' a GTK PuTTY window to the side of the screen (by dragging it to the RH edge, causing it to half-maximise over the right-hand half of the display, similarly to Windows), and then send a terminal resize sequence, then PuTTY fails the assertion in term_resize_request_completed() which expects that an unacknowledged resize request was currently in flight. When drawing_area_setup() calls term_resize_request_completed() in response to the inst->term_resize_notification_required flag, it resets the inst->win_resize_pending flag, but doesn't reset inst->term_resize_notification_required. As a result, the _next_ call to drawing_area_setup will find that flag still set, and make a duplicate call to term_resize_request_completed, after the terminal no longer believes it's waiting for a response to a resize request. And in this 'docked to the right-hand side of the display' state, KDE apparently triggers two calls to drawing_area_setup() in quick succession, making this bug manifest. I could fix this by clearing inst->term_resize_notification_required. But inspecting all the other call sites, it seems clear to me that my original intention was for inst->term_resize_notification_required to be a flag that's only meaningful if inst->win_resize_pending is set. So I think a better fix is to conditionalise the check in drawing_area_setup so that we don't even check inst->term_resize_notification_required if !inst->win_resize_pending.