forked from amazingfate/loongoffice
9351d4d6a1
The MenuButton usually owns the PopupMenu that
gets set via MenuButton::SetPopupMenu, but so far
didn't dispose it, i.e. the PopupMenu was never
disposed.
As far as I understand, that is a preexisting issue,
but since
commit 6708246e20ce522e673f539369cd38687d2dd16d
Author: Michael Weghorn <m.weghorn@posteo.de>
Date: Thu Dec 5 11:06:48 2024 +0000
tdf#164093 tdf#157001 a11y: Improve menu window disposal
, not disposing the menu also means not disposing the
menu's MenuFloatingWindow (which gets created when the
popup menu shows), resulting in
warn:legacy.osl:563630:563630:vcl/source/window/window.cxx:307: Window ( 10MenuButton()) with live SystemWindows destroyed: 18MenuFloatingWindow()
Window ( 10MenuButton()) with live SystemWindows destroyed: 18MenuFloatingWindow()
and an assert getting triggered as mentioned in
tdf#164072 comment 16.
Fix this by letting the MenuButton take care of
disposing the menu if it is the owner.
The only case where the MenuButton is assigned a menu
without taking ownership is in
SalInstanceComboBox::set_item_menu (which currently only
gets called from SvxStyleBox_Base::SetupEntry).
In that case, the weld::Menu passed to
SalInstanceComboBox::set_item_menu has the ownership:
SalInstanceBuilder::weld_menu calls the
SalInstanceMenu ctor with a bTakeOwnership=true,
and the SalInstanceMenu dtor disposes the menu.
Add a `bTakeOwnership` bool param to MenuButton::SetPopupMenu
to distinguish between the cases where the PopupMenu
is responsible for disposing the menu and where it's not.
Change-Id: I32766d5084e4826056ef394a587b8c2e3124c4da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178197
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
(cherry picked from commit 90d9b6e12f0aa9a569958586832bd4abe9561197)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178200
These are includes which are now only used by the toolkit module, which exposes them via uno. Don't use these in any new code.