wxPopupTransientWindow: don't destroy twice (PR #26083)

Bill Su

unread,

Jan 9, 2026, 12:18:35 AM (3 days ago) Jan 9

to wx-...@googlegroups.com, Subscribed

On wxMSW, if the dialogs sample with this tipwin-dismiss-race.patch runs in debug mode, then wxWidgets will soon wxASSERT() due to destroying a wxTipWindow instance twice.

To fix this problem, do not destroy an already-destroyed wxPopupTransientWindow .

You can view, comment on, or merge this pull request online at:

https://github.com/wxWidgets/wxWidgets/pull/26083

Commit Summary

adf0cb2 wxPopupTransientWindow: don't destroy twice

File Changes

(2 files)

M include/wx/tipwin.h (2)
M src/msw/popupwin.cpp (19)

Patch Links:

—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.

Bill Su

unread,

Jan 9, 2026, 12:45:23 AM (3 days ago) Jan 9

to wx-...@googlegroups.com, Push

@wsu-cb pushed 1 commit.

1b8f6f8 wxPopupTransientWindow: don't destroy twice

—
View it on GitHub or unsubscribe.
You are receiving this because you are subscribed to this thread.

VZ

unread,

Jan 10, 2026, 9:56:01 AM (yesterday) Jan 10

to wx-...@googlegroups.com, Subscribed

vadz left a comment (wxWidgets/wxWidgets#26083)

Thanks, but this seems a bit fishy to me, if we can get WM_ACTIVATE again, what guarantees that we get it before the window is scheduled for destruction, i.e. couldn't we still end up calling DismissOnDeactivate() twice? Is it really harmless?

Anyhow, I'll push this now as this seems to fix a real problem, but I'm far from sure that this is the best (or full) fix...

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.

VZ

unread,

Jan 10, 2026, 10:31:49 AM (yesterday) Jan 10

to wx-...@googlegroups.com, Subscribed

Closed #26083 via 89754f2.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.

Bill Su

unread,

Jan 10, 2026, 1:25:31 PM (yesterday) Jan 10

to wx-...@googlegroups.com, Subscribed

wsu-cb left a comment (wxWidgets/wxWidgets#26083)

Thanks, but this seems a bit fishy to me, if we can get WM_ACTIVATE again, what guarantees that we get it before the window is scheduled for destruction, i.e. couldn't we still end up calling DismissOnDeactivate() twice? Is it really harmless?

A second call to DismissOnDeactivate() is NOT harmless: it will trigger another call to Destroy() which is what triggers the wxASSERT() this PR is trying to avoid. I thought about simply changing the wxASSERT() to silently return (without adding the wxWindow to the schedule-for-destruction list) instead, but I thought the report of suspicious behavior was too useful to remove, which is why I used this approach.

Anyhow, I'll push this now as this seems to fix a real problem, but I'm far from sure that this is the best (or full) fix...

I won't be surprised if another way to double-Destroy() gets found, but I haven't seen it yet.

—
Reply to this email directly, view it on GitHub, or unsubscribe.

You are receiving this because you are subscribed to this thread.

VZ

unread,

Jan 10, 2026, 1:29:47 PM (yesterday) Jan 10

to wx-...@googlegroups.com, Subscribed

vadz left a comment (wxWidgets/wxWidgets#26083)

Sorry, I made a typo, I meant to write: "what guarantees that we don't get it before the window is scheduled for destruction". I.e. it looks like there is still a window (of time, not popup) when it can happen... But without debugging this to understand how does it happen exactly I don't know if it really can or not.