Bug 99388 - EDITING: crash when deleting comment
Summary: EDITING: crash when deleting comment
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Draw (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) All
: medium normal
Assignee: Armin Le Grand
Whiteboard: target:5.2.0
: 99642 100238 (view as bug list)
Depends on:
Reported: 2016-04-19 09:26 UTC by Gianfranco Cecconi
Modified: 2016-10-25 19:01 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Gianfranco Cecconi 2016-04-19 09:26:06 UTC
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 as it's the current version distributed with Fedora.

Comment 1 Usama 2016-04-19 15:02:57 UTC
Thank you for reporting this issue.

Confirmed on:

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 Ubuntu 15.10.
Comment 2 Julien Nabet 2016-04-19 19:55:05 UTC
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.
Comment 3 Julien Nabet 2016-04-19 19:56:16 UTC
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
Comment 4 Armin Le Grand 2016-04-20 13:40:33 UTC
Window::IsVisible() crashes with mpWindowImpl == nullptr -> Michael?
Comment 5 Armin Le Grand 2016-04-20 13:45:07 UTC
Huh - strange - it *gets* tested...
Comment 6 Armin Le Grand 2016-04-20 14:51:04 UTC
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.
Comment 7 Michael Meeks 2016-04-20 15:19:34 UTC
> 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 =)
Comment 8 Armin Le Grand 2016-04-21 08:44:58 UTC
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...
Comment 9 Armin Le Grand 2016-04-21 11:30:42 UTC
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...
Comment 10 Armin Le Grand 2016-04-21 13:11:42 UTC
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.
Comment 11 Armin Le Grand 2016-04-21 13:31:10 UTC
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...
Comment 12 Armin Le Grand 2016-04-21 14:13:01 UTC
Okay, solution is on gerrit (https://gerrit.libreoffice.org/#/c/24280/)
Comment 13 Commit Notification 2016-04-26 10:35:55 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":


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:

Affected users are encouraged to test the fix and report feedback.
Comment 14 Julien Nabet 2016-05-03 19:15:24 UTC
*** Bug 99642 has been marked as a duplicate of this bug. ***
Comment 15 Caolán McNamara 2016-05-24 14:26:25 UTC
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
Comment 16 Julien Nabet 2016-06-06 18:36:42 UTC
*** Bug 100238 has been marked as a duplicate of this bug. ***