To reproduce: import a PDF file, add a comment, write something in it, delete the comment using the pop-up menu in the bottom right corner of the comment, and Draw will crash. When recovering, the recovered document will correctly lack the comment that was just deleted. This suggests that the crash is caused by something that happens just after successfully deleting the comment. I'm using 5.0.5.2 as it's the current version distributed with Fedora. Thanks!
Thank you for reporting this issue. Confirmed on: Version: 5.2.0.0.alpha0+ Build ID: aaca25d67eb5ea252730cdcf555ecc04ce04a5e6 CPU Threads: 4; OS Version: Linux 4.2; UI Render: default; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-02-24_23:58:47 Locale: en-US (en_US.UTF-8) OS: Ubuntu 15.10 Unable to reproduce on 5.0.5.2 Ubuntu 15.10.
On pc Debian x86-64 with master sources updated today, I could reproduce the crash. I noticed these logs on console: warn:legacy.osl:3153:1:vcl/source/window/window.cxx:325: Window ( N2sd16AnnotationWindowE()) with live SystemWindows destroyed: 18MenuFloatingWindow() Michael/Noel: thought you might be interested in this one.
BTW, no need to import a pdf, you can just do: - launch Draw - insert comment - right click on bottom right corner of the comment - try to delete it => crash
Window::IsVisible() crashes with mpWindowImpl == nullptr -> Michael?
Huh - strange - it *gets* tested...
In AnnotationTag the opened AnnotationWindow loses focus, that leads to it's close/destruction (AnnotationTag, WindowEventHandler). It should not, the focus is lost since the added dropdown button is pressed. Result is that the living window is destructed at a bad point in time. The mechanism is constructed to clos the popped-up window ehen LO loses focus, but this needs somehow be limited to app losing focus, should not trigger by losing focus due to a sub-window popup getting the focus.
> Window::IsVisible() crashes with mpWindowImpl == nullptr -> Michael? bool Window::IsVisible() const { return mpWindowImpl && mpWindowImpl->mbVisible; } Is it possible that some magic happened to 'mpWindowImpl' - changing its pointer type such that now the && is an operator which gets inserted & thus needs to evaluate both its arguments thus killing the short-circuit ? - could be but ... could be the debugger lying too =)
The button bottom-right in the comment is no real button, it's hand-drawn and checked on MouseButtonDown with it's BoundRect. This leads to execution of a PopupMenu which gets and steals focus and makes the comment window to be destroyed. Lets see how to come in-between...
Have a working solution where I remember that the PopupMenu is active at the AnnotationWindow and use that at AnnotationTag WindowEventHandler to not trigger AnnotationTag ClosePopupHdl. Would be even better to not get such an VCLEVENT_WINDOW_DEACTIVATE. Checked and saw that the sender (Window::ImplCallDeactivateListeners) only sends when not a child. Interestingly, the PopupMenu is opened with AnnotationWindow as parent, but the active window is the AnnotationTextWindow. May be better when opening the PopupMenu with AnnotationTextWindow as parent, checking...
Using AnnotationTextWindow does not work since Window::ImplIsChild gets bSystemWindow == false and does not traverse down the chain. When forcing bSystemWindow == true it works. This also works for the original AnnotationWindow.
IsChild() with bSystemWindow == true works, but not in AnnotationTag::WindowEventHandler since there the chils (the PopupMenu) is not available. Thus this change would have to be done in Window::ImplCallDeactivateListeners in the ImplIsChild call. I can not say if that is wanted/appreciated. Michael? Will prepare fix with flag in AnnotationWindow for now...
Okay, solution is on gerrit (https://gerrit.libreoffice.org/#/c/24280/)
Armin Le Grand committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=ed42a984099b8847aedbdd638c7e20e0b68a9290 tdf#99388 suppress close comment when PopupMenu is active It will be available in 5.2.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 99642 has been marked as a duplicate of this bug. ***
This is fallout from commit dd46727b99d4bb5135451aa7e5e1bdb197373843 Author: Caolán McNamara <caolanm@redhat.com> Date: Tue Apr 5 15:27:38 2016 +0100 Resolves; tdf#87120 no keyboard navigation inside floating windows
*** Bug 100238 has been marked as a duplicate of this bug. ***