PuTTY bug scrollbar-sub-message-loop

This is a mirror. Follow this link to find the primary PuTTY web site.

Home | FAQ | Feedback | Licence | Updates | Mirrors | Keys | Links | Team
Download: Stable · Snapshot | Docs | Changes | Wishlist

summary: Dragging the Windows terminal scrollbar blocks handling of many non-GUI events
class: bug: This is clearly an actual problem we want fixed.
difficulty: mayhem: Probably impossible
priority: low: We aren't sure whether to fix this or not.

On Windows PuTTY, if you click on the terminal's scrollbar thumb and start dragging it interactively, then while you're performing that drag operation, PuTTY does not respond to various types of event:

All of those types of event are handled by PuTTY's top-level message loop, which is much more complicated than a simple loop on GetMessage: instead, it calls MsgWaitForMultipleObjects to watch file handles and event objects as well as window messages, and it sets the timeout on that call to handle timers.

But Windows's handling for an interactive drag of that scrollbar works by running a subsidiary Windows message loop that lasts for the duration of the drag. And that subsidiary message loop doesn't contain any of that extra complexity: it does just loop round on GetMessage, so all those other types of event are ignored until the interactive drag has finished.

I list this bug at 'mayhem' difficulty because there's not really any way to get round it, that I can see. The sub-message-loop (called from DefWindowProc's default handler for the WM_SYSCOMMAND/SC_VSCROLL message sent at the start of the drag) is the only thing in the Windows GUI implementation that knows the right way to translate mouse motion events during the drag into the WM_SCROLL/SB_THUMBTRACK window messages that tell you where to actually scroll to. So your choices are to let Windows run its sub-message-loop, or else reimplement that whole piece of GUI functionality completely by hand, and of course, you've got no chance of getting it all right.

Another option would be to make PuTTY a fundamentally multithreaded program, so that the window message loop could run in one thread and the handlers for other kinds of event could run in another. But PuTTY has had 25 years of being an essentially single-threaded code base (it does have sub-threads but they do extremely small jobs carefully separated from the main code), and converting it into something concurrency-safe at this late date would be tantamount to a rewrite from scratch!


If you want to comment on this web site, see the Feedback page.
Audit trail for this bug.
(last revision of this bug record was at 2021-05-02 11:23:46 +0100)