I have basically the same issue as described in Bug ID 120222. I apologize if it was incorrect not to comment in the thread for this Bug ID. I am running the following version: Version: 24.8.3.2 (AARCH64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: macOS 14.4; UI render: Skia/Metal; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded The problem can be produced as follows: 1) Create a new document in Writer 2) Write at least two characters 3) Add one comment to each character 4) Attempt to "delete all comments" or "delete all comments by" => LibreOffice crashes completely and immediately The issue also occurs in safe mode for me and with completely new documents that contain no content at all. Thank you in advance for your help!!
I can't reproduce it in Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7a7ba9cbee91485a9254949d1594352b3629c070 CPU threads: 8; OS: Linux 6.1; UI render: default; VCL: gtk3 Locale: es-ES (es_ES.UTF-8); UI: en-US Calc: threaded Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it. See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Maybe MacOS only ?
Created attachment 197826 [details] File contains two words and two comments to illustrate the crash
(In reply to Xisco Faulí from comment #2) > Maybe MacOS only ? This is possible. I am unsure how to find the crash report and upload it here on macOS. LibreOffice does not automatically generate a report.
I cannot reproduce this bug. I see no crash when I select the Edit > Comment > Delete All Comments or Delete All Comments by Author menu items: Version: 24.8.3.2 (AARCH64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: macOS 15.1.1; UI render: Skia/Metal; VCL: osx Locale: en-CA (en_CA.UTF-8); UI: en-US Calc: threaded
(In reply to Patrick (volunteer) from comment #5) > I cannot reproduce this bug. I see no crash when I select the Edit > Comment > > Delete All Comments or Delete All Comments by Author menu items: > > Version: 24.8.3.2 (AARCH64) / LibreOffice Community > Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 > CPU threads: 8; OS: macOS 15.1.1; UI render: Skia/Metal; VCL: osx > Locale: en-CA (en_CA.UTF-8); UI: en-US > Calc: threaded Very interesting! Can you try to right-click on a comment and select "delete all comments" from there? I will check whether "Edit > Comment > > Delete All Comments" works for me.
(In reply to rjnonym from comment #6) > Very interesting! Can you try to right-click on a comment and select "delete > all comments" from there? I will check whether "Edit > Comment > > > Delete All Comments" works for me. No crash with either popup menu item. Does the crash still occur if you restart LibreOffice in safe mode by selecting the Help > Restart in Safe Mode menu item?
Rjnonym: if you still reproduce this in safe mode (as Patrick suggested), would it be possible you follow https://wiki.documentfoundation.org/QA/BugReport/Debug_Information#macOS:_How_to_get_debug_information to provide extra info?
(In reply to Patrick (volunteer) from comment #7) > (In reply to rjnonym from comment #6) > > Very interesting! Can you try to right-click on a comment and select "delete > > all comments" from there? I will check whether "Edit > Comment > > > > Delete All Comments" works for me. > > No crash with either popup menu item. > > Does the crash still occur if you restart LibreOffice in safe mode by > selecting the Help > Restart in Safe Mode menu item? So, I was able to further research this. 1) The crash does NOT occur when I use Edit > Comment > Delete All Comments. This could explain why the issue is not widely known, if it affects many installations at all. I apologize for not checking this earlier. 2) The crash occurs ONLY when right-clicking on the comment in the sidebar and selecting Delete All Comments (by Author) in the context menu. 3) This context-menu crash occurs both in normal and in safe mode.
[Automated Action] NeedInfo-To-Unconfirmed
I tried it on windows, but doesn't crash either Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Vulkan; VCL: win Locale: es-CO (es_CO); UI: es-ES Calc: CL threaded
(In reply to Sirlaed from comment #11) > I tried it on windows, but doesn't crash neither > > Version: 24.8.3.2 (X86_64) / LibreOffice Community > Build ID: 48a6bac9e7e268aeb4c3483fcf825c94556d9f92 > CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: > Skia/Vulkan; VCL: win > Locale: es-CO (es_CO); UI: es-ES > Calc: CL threaded
(In reply to rjnonym from comment #9) > So, I was able to further research this. > > 1) The crash does NOT occur when I use Edit > Comment > Delete All Comments. > This could explain why the issue is not widely known, if it affects many > installations at all. I apologize for not checking this earlier. > > 2) The crash occurs ONLY when right-clicking on the comment in the sidebar > and selecting Delete All Comments (by Author) in the context menu. > > 3) This context-menu crash occurs both in normal and in safe mode. I tried both #1 and #2 and was not able to reproduce the crash. Version: 24.8.2.1 (AARCH64) / LibreOffice Community Build ID: 0f794b6e29741098670a3b95d60478a65d05ef13 CPU threads: 8; OS: macOS 14.5; UI render: Skia/Metal; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
(In reply to rjnonym from comment #9) > 2) The crash occurs ONLY when right-clicking on the comment in the sidebar > and selecting Delete All Comments (by Author) in the context menu. No crash for me. Arch Linux 64-bit Version: 24.8.3.2 (X86_64) / LibreOffice Community Build ID: 480(Build:2) CPU threads: 8; OS: Linux 6.11; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US 24.8.3-1 Calc: threaded
Created attachment 197984 [details] bt On pc Debian x86-64 with master sources updated today, I could reproduce this with gen rendering (not with gtk3 rendering).
I noticed this on console: 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()
(In reply to Julien Nabet from comment #16) > I noticed this on console: > 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() IIUC, this (and the related crash with the backtrace in comment 15) is unrelated to the original problem reported here and should be fixed by https://gerrit.libreoffice.org/c/core/+/178197 .
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/90d9b6e12f0aa9a569958586832bd4abe9561197 tdf#164072 vcl: Let MenuButton dispose its PopupMenu It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/9351d4d6a131b7e4c05a5762ef74789d37054aa3 tdf#164072 vcl: Let MenuButton dispose its PopupMenu It will be available in 25.2.0.0.beta2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I am uncertain whether the bug has been identified as of now. I was able to find some time to get back to the issue now. Neither LibreOffice nor macOS Crash Reporter generated any crash reports and I could not get them to do so (perhaps a separate bug). Best I could do is make a short screen recording that shows the bug: https://web.tresorit.com/l/QQsQj#wZBGeccItmVUUZnBYSfAHw I hope that helps!
(In reply to rjnonym from comment #20) > I am uncertain whether the bug has been identified as of now. I was able to > find some time to get back to the issue now. Neither LibreOffice nor macOS > Crash Reporter generated any crash reports and I could not get them to do so > (perhaps a separate bug). Best I could do is make a short screen recording > that shows the bug: https://web.tresorit.com/l/QQsQj#wZBGeccItmVUUZnBYSfAHw > > I hope that helps! Please use: https://we.tl/t-MrsphGyNTz instead!
*** Bug 164801 has been marked as a duplicate of this bug. ***
Mentioned on the duplicate that it crashes when the command is run via context menu on the comments bar but not via the menu bar. Highly important/severe since affecting 25.2.
(In reply to Heiko Tietze from comment #23) > Mentioned on the duplicate that it crashes when the command is run via > context menu on the comments bar but not via the menu bar. Highly > important/severe since affecting 25.2. About information is missing, please provide it. OTOH, have you tried with GEN environment ?
Not reproducible in Version: 24.8.4.2 (X86_64) / LibreOffice Community Build ID: bb3cfa12c7b1bf994ecc5649a80400d06cd71002 CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded
I repro with a debug build, but not otherwise. kf5, kf6, gen, NOT gtk3. Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: bebadddfb999f678a44cdc486dfd91f38e563c9f CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
(In reply to Buovjaga from comment #26) > I repro with a debug build, but not otherwise. kf5, kf6, gen, NOT gtk3. > > Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: bebadddfb999f678a44cdc486dfd91f38e563c9f > CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland) > Locale: fi-FI (fi_FI.UTF-8); UI: en-US > Calc: CL threaded I can NOT reproduce with gen/kf5/qt6 and local debug build. Do you have a backtrace? tdf#164801 at first glance looks like the (debug-build only) crash/assert that is meant to be fixed by the commit in comment 18 (which IIUC, is different what this ticket originally for macOS and presumably a release build used to be about). Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5d2b2b9f381bbfb19ffd393f361c1fdd4a898550 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: x11 Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5d2b2b9f381bbfb19ffd393f361c1fdd4a898550 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 5d2b2b9f381bbfb19ffd393f361c1fdd4a898550 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: qt6 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: CL threaded
Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 7f4901ded76fa3f3dffaef2d8f68d5c4803d98a2 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded console message: warn:legacy.osl:349765:349765:vcl/source/window/window.cxx:307: Window ( N2sw10annotation15SwAnnotationWinE()) with live SystemWindows destroyed: 18MenuFloatingWindow() Window ( N2sw10annotation15SwAnnotationWinE()) with live SystemWindows destroyed: 18MenuFloatingWindow() warn:vcl:349765:349765:vcl/source/control/prgsbar.cxx:175: StatusBar::SetProgressValue(): nPercent > 100 Issue seems to start at SwPostItMgr::RemoveItem() with latest changes by Noel in https://gerrit.libreoffice.org/c/core/+/179445
Created attachment 198892 [details] Backtrace from debug build
(In reply to Heiko Tietze from comment #28) > Issue seems to start at SwPostItMgr::RemoveItem() with latest changes by > Noel in https://gerrit.libreoffice.org/c/core/+/179445 How did you figure that? Because if I build with the commit before my changes, it still crashes in the same way.
(In reply to Noel Grandin from comment #30) > (In reply to Heiko Tietze from comment #28) > > Issue seems to start at SwPostItMgr::RemoveItem() with latest changes by > > Noel in https://gerrit.libreoffice.org/c/core/+/179445 > > How did you figure that? Because if I build with the commit before my > changes, it still crashes in the same way. Quickly skimmed over the lines and commits, and yours turning SwSidebarItem into SwAnnotationItem is the latest. Good if not, bibisection has been requested.
(In reply to Heiko Tietze from comment #31) > (In reply to Noel Grandin from comment #30) > > (In reply to Heiko Tietze from comment #28) > > > Issue seems to start at SwPostItMgr::RemoveItem() with latest changes by > > > Noel in https://gerrit.libreoffice.org/c/core/+/179445 > > > > How did you figure that? Because if I build with the commit before my > > changes, it still crashes in the same way. > > Quickly skimmed over the lines and commits, and yours turning SwSidebarItem > into SwAnnotationItem is the latest. Good if not, bibisection has been > requested. Can't be done with our binaries, would need to compile at each step.
This appears to have started with 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
(In reply to Noel Grandin from comment #33) > This appears to have started with > > 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 commit 9351d4d6a131b7e4c05a5762ef74789d37054aa3 Author: Michael Weghorn <m.weghorn@posteo.de> Date: Tue Dec 10 08:31:24 2024 +0100 tdf#164072 vcl: Let MenuButton dispose its PopupMenu is supposed to fix the issue observable since that commit and does in my setup. Since I can't reproduce the remaining issue myself, it's hard to tell what's going wrong.
(In reply to Michael Weghorn from comment #34) > Since I can't reproduce the remaining issue myself, it's hard to tell > what's going wrong. OK, I can reproduce now when I right-click on a comment area in order to open the menu (as described in tdf#164801). (Previously, I was left-clicking the "small triangle" on a comment to open the menu, in which case the assert doesn't get triggered. Will take a look, but might only really get to it sometime after FOSDEM.
Michael, in this specific case, I don't think this assert is telling us anything useful. So it may be worth simply making that assert a little more complex and excluding the case of popup menu objects.
(In reply to Noel Grandin from comment #36) > Michael, in this specific case, I don't think this assert is telling us > anything useful. So it may be worth simply making that assert a little more > complex and excluding the case of popup menu objects. Thanks, Noel. Disposing a child window before its parent doesn't seem ideal to me at first sight, so I've submitted a change with an approach that avoids that: https://gerrit.libreoffice.org/c/core/+/181110
(In reply to Michael Weghorn from comment #37) > Disposing a child window before its parent doesn't seem ideal to me at first > sight, (...) That was meant to be the other way around: "Disposing a parent window before its child doesn't seem ideal to me (...)."
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/0467f88e2892b36d6f89b626f0d273fa8c403a87 tdf#164072 sw annotation: Use menu parent that outlives menu It will be available in 25.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
No crash anymore Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a49021db6b5ee9afd9d72a3f20f2fb5579838e3e CPU threads: 8; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+wayland) Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: CL threaded
While the commit from comment 39 was primarily targeted at the assert in debug builds discussed earlier, I also cannot reproduce any crash on macOS with current master. It may be that the crash there was caused by the same underlying issue (menu parent disposed while menu is still used). When I revert the commit from comment 39 locally and comment the assert, I can still reproduce another crash with the following backtrace on macOS: 1 rtl::Reference<vcl::Window>::get() const ref.hxx 205 0x111e505f0 2 VclPtr<vcl::Window>::operator bool() const vclptr.hxx 187 0x111e6f2c8 3 vcl::Window::GetWindowExtentsRelative(vcl::Window const&) const window.cxx 2929 0x112171cd8 4 MenuFloatingWindow::doShutdown() menufloatingwindow.cxx 103 0x1120ab678 5 PopupMenu::FinishRun(VclPtr<MenuFloatingWindow> const&, VclPtr<vcl::Window> const&, bool, bool) menu.cxx 3106 0x1120992bc 6 PopupMenu::ImplExecute(VclPtr<vcl::Window> const&, tools::Rectangle const&, FloatWinPopupFlags, Menu *, bool) menu.cxx 3033 0x11209840c 7 PopupMenu::Execute(vcl::Window *, tools::Rectangle const&, PopupMenuFlags) menu.cxx 2860 0x112097198 8 VCLXMenu::execute(com::sun::star::uno::Reference<com::sun::star::awt::XWindowPeer> const&, com::sun::star::awt::Rectangle const&, short) vclxmenu.cxx 509 0x108864e4c 9 SfxDispatcher::ExecutePopup(rtl::OUString const&, vcl::Window *, Point const *) dispatch.cxx 1937 0x106fb0154 10 SfxDispatcher::ExecutePopup(vcl::Window *, Point const *) dispatch.cxx 1785 0x106faf7b4 11 sw::sidebarwindows::SidebarTextControl::Command(CommandEvent const&) SidebarTxtControl.cxx 443 0x442bc7048 12 weld::CustomWeld::DoCommand(CommandEvent const&) customweld.cxx 93 0x11284d438 13 weld::CustomWeld::LinkStubDoCommand(void *, CommandEvent const&) customweld.cxx 91 0x11284cf84 14 Link<CommandEvent const&, bool>::Call(CommandEvent const&) const link.hxx 105 0x112002f6c 15 SalInstanceDrawingArea::CommandHdl(CommandEvent const&) salvtables.cxx 6559 0x112897380 16 SalInstanceDrawingArea::LinkStubCommandHdl(void *, CommandEvent const&) salvtables.cxx 6557 0x112895000 17 Link<CommandEvent const&, bool>::Call(CommandEvent const&) const link.hxx 105 0x112002f6c 18 VclDrawingArea::Command(CommandEvent const&) layout.hxx 679 0x11206e704 19 ImplCallCommand(VclPtr<vcl::Window> const&, CommandEventId, void const *, bool, Point const *) winproc.cxx 229 0x1121877a0 20 ImplHandleMouseEvent(VclPtr<vcl::Window> const&, NotifyEventType, bool, long, long, unsigned long, unsigned short, MouseEventModifiers) winproc.cxx 798 0x112186ab0 21 ImplHandleSalMouseButtonDown(vcl::Window *, SalMouseEvent const *) winproc.cxx 2338 0x11218aeb4 22 ImplWindowFrameProc(vcl::Window *, SalEvent, void const *) winproc.cxx 2683 0x112189cb8 23 SalFrame::CallCallback(SalEvent, void const *) const salframe.hxx 311 0x1118cccf8 24 -[SalFrameView sendMouseEventToFrame:button:eventtype:] salframeview.mm 1093 0x111976474 25 -[SalFrameView rightMouseDown:] salframeview.mm 1160 0x111976a98 26 _routeRightMouseDownEvent (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19bb79308 27 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19b11bec4 28 -[NSWindow(NSEventRouting) sendEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19b11bb50 29 -[NSApplication(NSEventRouting) sendEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19b9580b8 30 -[VCL_NSApplication sendEvent:] vclnsapp.mm 203 0x111982450 31 AquaSalInstance::DoYield(bool, bool) salinst.cxx 609 0x1118e76d4 32 ImplYield(bool, bool) svapp.cxx 385 0x112914a18 33 Application::Yield() svapp.cxx 488 0x1129142d0 34 Application::Execute() svapp.cxx 360 0x112913fac 35 desktop::Desktop::Main() app.cxx 1679 0x100a6fe04 36 ImplSVMain() svmain.cxx 230 0x112935fd8 37 AquaSalInstance::handleAppDefinedEvent(NSEvent *) salinst.cxx 449 0x1118e68d8 38 -[VCL_NSApplication sendEvent:] vclnsapp.mm 93 0x11198203c 39 -[NSApplication _handleEvent:] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19b55f4e8 40 -[NSApplication run] (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19afe8088 41 NSApplicationMain (arm64e) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit 0x19afbe854 42 AquaSalInstance::SVMainHook(int *) salinst.cxx 1107 0x1118ebaec 43 ImplSVMain() svmain.cxx 223 0x112935f8c 44 SVMain() svmain.cxx 248 0x112937aac 45 soffice_main sofficemain.cxx 122 0x100aef61c 46 sal_main main.c 51 0x100003f70 47 main main.c 49 0x100003f48 48 start (arm64e) /usr/lib/dyld 0x197024274 Frame 4 is making use of the parent window, which is already disposed at this stage without the fix from comment 39. Therefore, I'm somewhat optimistic that the original issue that this ticket was about is fixed now, too. -> Closing this ticket as fixed. @Reporter: A retest with a current daily build to see whether it's fine for you as well now would be welcome. Feel free to reopen if it still crashes for you. Version: 25.8.0.0.alpha0+ (AARCH64) / LibreOffice Community Build ID: 4906f11d8f0c85248464b10c0b6c9c02e1657bad CPU threads: 10; OS: macOS 15.2; UI render: Skia/Metal; VCL: osx Locale: en-US (en_DE.UTF-8); UI: en-US Calc: threaded
Verifying with Version: 25.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2cd3c9fdd05336b17bda301eb37c1ca86b062052 CPU threads: 32; OS: Linux 6.12; UI render: default; VCL: kf6 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded Thank you, Michael! Please cherry-pick to 25.2
(In reply to Heiko Tietze from comment #42) > Please cherry-pick to 25.2 Already pending in Gerrit, waiting for reviewers: https://gerrit.libreoffice.org/c/core/+/181134
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-25-2": https://git.libreoffice.org/core/commit/fc2394d4774a0835d028b60f52e16c02597a02d4 tdf#164072 sw annotation: Use menu parent that outlives menu It will be available in 25.2.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.