[Git][wxwidgets/wxwidgets][master] 17 commits: Don't notify already destroyed wxEventLoopSourceHandler in wxGTK

4 views
Skip to first unread message

Vadim Zeitlin (@_VZ_)

unread,
Sep 22, 2026, 5:28:09 PMSep 22
to wx-commi...@googlegroups.com

Vadim Zeitlin pushed to branch master at wxWidgets / wxWidgets

Commits:

  • d42bc799
    by Vadim Zeitlin at 2026-09-21T01:57:14+02:00 
    Don't notify already destroyed wxEventLoopSourceHandler in wxGTK

It doesn't make sense to continue reporting any events on a source that
has been destroyed, it doesn't need them any more and we could crash
using now dangling pointers and, worse, we could wrongly process the
notifications for a new source reusing the same FD.

This was the root source of multiple problems in wxWebRequestCURL and
could also cause them elsewhere.
  • 91752129
    by Vadim Zeitlin at 2026-09-21T01:57:14+02:00 
    Revert hack in wxWebRequestCURL not needed any more

This reverts 4e0fca8ab9 (Fix crash when connection is refused in
wxWebRequestCURL, 2024-10-27) which is not needed any longer after the
underlying bug in wxGTK event loop has been fixed.

See #24885.
  • 75b1f8ae
    by Vadim Zeitlin at 2026-09-21T14:08:50+02:00 
    Add a unit test exercising now fixed bugs in wxWebRequestCURL

The new tests check for the problems that resulted in crashes or hangs
before but work correctly now.

See #24885, #27040.
  • 1b775d77
    by Vadim Zeitlin at 2026-09-21T14:08:50+02:00 
    Fix passing wrong flags to wxEventLoopSourceHandler in wxQt

wxQtEventLoopSource ctor passed the file descriptor instead of flags to
the base class ctor expecting the latter.
  • 86415be2
    by Vadim Zeitlin at 2026-09-21T16:46:54+02:00 
    Fix returning wrong value of wxGenericListCtrl::GetCountPerPage()

The value could have been cached for the size which has changed since it
was computed, making it wrong.

In practice, this resulted in a failure in "ListCtrl::Visible" unit test
in wxGTK when GTK_OVERLAY_SCROLLING=0 was set. This happened because the
initial window size was computed assuming that the scrollbars would be
shown (with overlay scrollbars we never reserve any space for them) and
the value of lines fitting per page became wrong later when it turned
out that no scrollbars were necessary.

The test passes both with and without GTK_OVERLAY_SCROLLING=0 now.
  • e50c794c
    by Vadim Zeitlin at 2026-09-21T16:46:54+02:00 
    Extract wxGetScrollbarSpacing() function from wxGTK wxWindow

No real changes, just factor out this function to allow reusing it in
the upcoming commit.
  • 417785fb
    by Vadim Zeitlin at 2026-09-21T16:46:54+02:00 
    Fix GetScrollbarSize() in wxGTK when scrollbar-spacing is non-0

It is 0 in the default theme with GTK 3, but may be potentially non-0
even in it too and it's 3 by default with GTK 2, so GetScrollbarSize()
didn't return the correct result there.

Make it work in all cases by ensuring that GetScrollbarSize() and
DoGetClientSize() agree.
  • f3878633
    by Vadim Zeitlin at 2026-09-21T16:46:55+02:00 
    Use GetScrollbarSize() instead of wxSYS_HSCROLL_[XY]

When determining the size of a window, GetScrollbarSize() should be used
instead of using the metrics values because the function takes into
account the case of overlay scrollbars, which are used by default with
GTK 3, unlike the metric value.

Also update the documentation to recommend doing this.
  • 15df4980
    by Robert Roebling at 2026-09-21T16:46:55+02:00 
    Fix best size computation in wxGenericTreeCtrl

Implement DoGetBestClientWidth() so that the control can compute the
appropriate width when its height is known, as is the case when it's
used as wxTreeBook controller: this prevents the appearance of ugly
and unnecessary horizontal scrollbar in this case.

Add a unit test checking that the best size is computed correctly.

Closes #26097.

Co-authored-by: Vadim Zeitlin <va...@wxwidgets.org>
  • 33325282
    by Steve Cornett at 2026-09-22T08:25:20-07:00 
    Fix wxToolBar dark mode button background status

Show tool bar buttons in the pressed state regardless of whether the mouse is hovering.
  • b4c69b34
    by Steve Cornett at 2026-09-22T08:30:57-07:00 
    Fix wxToolBar dark mode button colour

Use gray colour for wxToolBar buttons when pressed/checked in dark mode.
  • 3b1bd2a6
    by Vadim Zeitlin at 2026-09-22T23:00:40+02:00 
    Merge branch 'webrequest-curl-real-fix'

Fix bug in wxGTK event loop implementation responsible for
wxWebRequestCURL bugs.

See #27041.
  • a16da690
    by Vadim Zeitlin at 2026-09-22T23:03:06+02:00 
    Merge branch 'generic-treectrl-getbestclientwidth'

Fix best size computation in wxGenericTreeCtrl and several bugs
discovered while working on this.

See #27043.
  • f91f5ae2
    by Quin Gillespie at 2026-09-22T23:07:25+02:00 
    Allow giving focus to read-only wxTextCtrl from keyboard in wxMSW

In wxMSW, single line read-only wxTextCtrl doesn't accept focus from
keyboard, so keyboard and screen reader users can't Tab to it and read
its contents.

Add wxWindow::EnableFocusFromKeyboard(), the counterpart of the existing
DisableFocusFromKeyboard(), to let the application allow this.

Update the documentation and add a wxMSW-only unit test.

Fixes #10760.

Closes #27054.
  • e5c3f01b
    by Quin Gillespie at 2026-09-22T23:08:26+02:00 
    Fix VoiceOver not showing wx context menus under macOS

VoiceOver users open context menus with VO-Shift-M (where "VO" is the
configured modifier key), which calls accessibilityPerformShowMenu on
the element. wxWidgets didn't handle it, so wxEVT_CONTEXT_MENU was never
generated: nothing happened for most controls, and text controls showed
their native editing menu instead of the one defined by the application.

Now accessibilityPerformShowMenu sends wxEVT_CONTEXT_MENU, with
wxDefaultPosition as for the other keyboard-initiated context menus, and
falls back to the native behaviour if the event is not handled, so text
controls still show their native menu in this case.

Fixes #13010.

Closes #27061.
  • f07dfda9
    by Vadim Zeitlin at 2026-09-22T23:18:46+02:00 
    Merge branch 'wxToolBar-background' of github.com:stevecor/wxWidgets

Improve wxToolBar dark mode button background drawing in wxMSW.

See #27064.
  • 14e2f80f
    by Vadim Zeitlin at 2026-09-22T23:23:38+02:00 
    Avoid spurious errors from wxUILocale::GetPreferredUILanguages()

The registry key used by this function under MSW can be absent (at least
when using Wine), but this is not really an error, so don't log it.

Closes #27067.

39 changed files:

The diff was not included because it is too large.
Reply all
Reply to author
Forward
0 new messages