Bug 106131 - Crash when the anchor icon is dropped outside of the document ( steps comment 24 )
Summary: Crash when the anchor icon is dropped outside of the document ( steps comment...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2 all versions
Hardware: All All
: highest critical
Assignee: Armin Le Grand (CIB)
QA Contact:
URL:
Whiteboard: target:5.5.0 target:5.4.0.1 target:5.3.4
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks:
 
Reported: 2017-02-21 20:13 UTC by Roman
Modified: 2017-05-30 22:35 UTC (History)
5 users (show)

See Also:
Crash report or crash signature: ["SdrHdl::SetSelected(bool)"]


Attachments
This is what I meant by "height" of the mouse. You can see the cursor on the right. (135.43 KB, image/png)
2017-02-24 14:57 UTC, Roman
Details
Step 1. Select and drag, but make sure to have a preview like this one. (132.63 KB, image/png)
2017-02-24 15:03 UTC, Roman
Details
Step 2. Release the left mouse button and line should dissapear completely. (110.41 KB, image/png)
2017-02-24 15:04 UTC, Roman
Details
Step 3.Click somewhere on the page, Writer closes and this window appears. (50.93 KB, image/png)
2017-02-24 15:08 UTC, Roman
Details
This is the crash report. (68.14 KB, image/png)
2017-02-24 15:10 UTC, Roman
Details
Line ends here after I reopen the document. Nothing is lost. (113.03 KB, image/png)
2017-02-24 15:11 UTC, Roman
Details
The file I used to reproduce the bug. (19.96 KB, application/vnd.oasis.opendocument.text)
2017-02-24 15:16 UTC, Roman
Details
screencast (2.79 MB, video/ogg)
2017-05-21 23:33 UTC, Xisco Faulí
Details
backtrace (20.91 KB, text/x-log)
2017-05-21 23:52 UTC, Xisco Faulí
Details
bt with debug symbols (4.40 KB, text/plain)
2017-05-25 16:06 UTC, Julien Nabet
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Roman 2017-02-21 20:13:19 UTC
Description:
It just crashes LibreOffice Writer and gives me this link
http://crashreport.libreoffice.org/stats/crash_details/535a76bf-d33f-4715-91ea-f1be968f8261,
after that all my documents are restored successfully.


Steps to Reproduce:
1.Draw a vertical line with the "height" of the mouse
2.Move it between two lines of text
3.If it disappears, left-click somewhere on the page

Actual Results:  
LibreOffice Writer crashes.

Expected Results:
The line to be moved between the text-lines


Reproducible: Always

User Profile Reset: No

Additional Info:


User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:51.0) Gecko/20100101 Firefox/51.0
Comment 1 Roman 2017-02-21 20:24:31 UTC
edit: *step2. left-click on the anchor symbol and drag it to the left side of the page
Comment 2 Roman 2017-02-21 20:37:46 UTC
actually, it like just moving the line in the page, placing it somewhere and then pressing the left mouse button causes Writer to crash
Comment 3 Roman 2017-02-21 20:38:27 UTC
*it looks like
Comment 4 Julien Nabet 2017-02-22 23:32:29 UTC
Any better with LO 5.2.5 or with 5.3.0?

BTW, I didn't understand your step by step process.
1) What's the height of the mouse?
2) the line is vertical, how could it be between 2 lines of text? Do you mean you write vertically (eg: you write in Japanese)?
Comment 5 Roman 2017-02-24 14:57:33 UTC
Created attachment 131447 [details]
This is what I meant by "height" of the mouse. You can see the cursor on the right.
Comment 6 Roman 2017-02-24 15:03:09 UTC
Created attachment 131448 [details]
Step 1. Select and drag, but make sure to have a preview like this one.
Comment 7 Roman 2017-02-24 15:04:35 UTC
Created attachment 131449 [details]
Step 2. Release the left mouse button and line should dissapear completely.
Comment 8 Julien Nabet 2017-02-24 15:06:22 UTC
To make it easy to reproduce this, could you attach your file by using this link
https://bugs.documentfoundation.org/attachment.cgi?bugid=106131&action=enter ?
Comment 9 Roman 2017-02-24 15:08:18 UTC
Created attachment 131450 [details]
Step 3.Click somewhere on the page, Writer closes and this window appears.

Text is in russian. It says that LibreOffice crashed because of an unexpected error and that my files are saved and will be restored when I open LibreOffice again.
Comment 10 Roman 2017-02-24 15:10:27 UTC
Created attachment 131452 [details]
This is the crash report.
Comment 11 Roman 2017-02-24 15:11:53 UTC
Created attachment 131453 [details]
Line ends here after I reopen the document. Nothing is lost.
Comment 12 Roman 2017-02-24 15:15:16 UTC
It was a little harder to grab onto a line in the way I described after I updated LO to 5.2.5.1 but I was still able to crash LO a couple of times.
Updated the crash report.
Comment 13 Roman 2017-02-24 15:16:43 UTC
Created attachment 131454 [details]
The file I used to reproduce the bug.
Comment 14 Roman 2017-02-24 15:18:16 UTC
I was able to reproduce the bug in a newly created file.
Comment 15 Xisco Faulí 2017-03-02 11:57:59 UTC
Hello Roman,
it seems really difficult to follow the steps only with images. Could you please update a screencast instead?
Comment 16 Roman 2017-03-08 17:34:55 UTC
Here is a link to a Youtube video about this bug,
http://youtu.be/SuY4PhI1RaI?hd=1
Comment 17 Julien Nabet 2017-03-08 17:48:14 UTC
Version must correspond to the oldest one for which the bug can be encountered.
Comment 18 Xisco Faulí 2017-03-09 10:08:57 UTC Comment hidden (obsolete)
Comment 19 Roman 2017-03-11 20:49:48 UTC
Tried the newer version, 5.3.0.3, and it still crashes.
Here is the crash-report: crashreport.libreoffice.org/stats/crash_details/191de41b-886c-4bd1-ad3c-6ff023670ec5
Comment 20 Aron Budea 2017-03-12 02:11:56 UTC
I managed to reproduce the crash in 5.2.5.1 / Windows 7 once, but not a second time:
http://crashreport.libreoffice.org/stats/crash_details/050742e8-5b60-4769-b30d-2cff5e9c5689

Quite tricky.
Comment 21 Buovjaga 2017-03-13 09:30:00 UTC
I could reproduce, but it was hard work :)
I think making it disappear + clicking somewhere is key as that's when it happened for me.

I'll leave priority as medium because this is so hard to repro.

Win 7 Pro 64-bit Version: 5.4.0.0.alpha0+
Build ID: eb7b03b052ffe8c2c577b2349987653db6c53f76
CPU threads: 4; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2017-02-26_22:34:18
Locale: fi-FI (fi_FI); Calc: CL
Comment 22 Xisco Faulí 2017-05-21 23:33:03 UTC
Created attachment 133443 [details]
screencast
Comment 23 Xisco Faulí 2017-05-21 23:35:09 UTC
Steps to reproduce:
1. Draw an object on the left-top corner of the page ( make sure it's drawn where the anchor is )
2. Click on the object, and by clicking above the anchor, drag and drop it outside the page.
3. Repeat until it crashes
Comment 24 Xisco Faulí 2017-05-21 23:50:21 UTC
Steps to reproduce:
1. Draw an object on the left-top corner of the page ( make sure it's drawn where the anchor is )
2. Click on the object, and by clicking above the anchor, drag and drop it outside the page.
3. Click where the object is dropped
Comment 25 Xisco Faulí 2017-05-21 23:52:15 UTC
Created attachment 133444 [details]
backtrace
Comment 26 Xisco Faulí 2017-05-22 00:10:45 UTC
Regression introduced in

author	Armin Le Grand <alg@apache.org>	2012-12-13 08:47:57 (GMT)
committer	Caolán McNamara <caolanm@redhat.com>	2013-06-13 09:37:03 (GMT)
commit	67608078a857fc128efc6bf4172f9ce4384d25c7 (patch)
tree	b35538ea67ffdf00a83d1a8de17df3b96e2be537
parent	de435e745ad8c32640342675103a48383a84b5a9 (diff)
Resolves: #i121463# Enhanced handle visualization..
and some fixes in that region

Bisected with bibisect-42max.

Adding Cc: to Armin Le Grand
Comment 27 Julien Nabet 2017-05-25 16:06:43 UTC
Created attachment 133577 [details]
bt with debug symbols

On pc Debian x86-64 with master sources updated yesterday, I could reproduce this but had a different bt.
(gtk3 rendering)
Comment 28 Armin Le Grand (CIB) 2017-05-25 16:11:19 UTC
Could finally reproduce with screencast from comment 22. Taking a look...
Comment 29 Armin Le Grand (CIB) 2017-05-25 17:03:46 UTC
Problem is that there is no SwEditWin::MouseButtonUp call when releasing the anchor handle. It should come from ImplHandleMouseEvent winproc.cxx, but does not. This is clearly an error, a MouseButtonDown *not* followed by a MouseButtonUp. This leads to SwAnchorMarker containing a non-valid pointer to SdrHdl. If that is acessed using m_pAnchorMarker->GetHdl()->SetSelected(false) it crashes.
Lets see why there is no MouseButtonUp event...
Comment 30 Armin Le Grand (CIB) 2017-05-25 17:44:56 UTC
There seems to be no MouseButtonUp due to a SalEvent::MouseLeave that is triggered. That again seems to happen since a 'drag' gets started (which may be right, the anchor gets dragged). bMouseLeave in ImplHandleMouseEvent gets true, a MouseMove is created instead of MouseButtonUp.
All this happens when the anchor symbol and the object anchored overlap like with the rectangle example. If no overlap, all works well.
Thus the overlap and MouseButtonDown seems to initiate two things at once - the anchor drag and the object drag (ß). Need to check that. ANyways, *nothing* should lead to Win's getting a MouseButtonUp without a MouseButtonDown pairing.
Comment 31 Armin Le Grand (CIB) 2017-05-26 09:53:18 UTC
Identified where the global object drag mode gets activated, in SwEditWin::StartDrag cases for frame and draw object already being dragged are handled, but not the case that the anchor drag is active. Added this, solution is on gerrit
Comment 32 Commit Notification 2017-05-26 12:02:56 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b27bed2d5b6915cda408c6f8d27d15bf13cc9be

tdf#106131 no global drag when anchor drag active

It will be available in 5.5.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.
Comment 33 Armin Le Grand (CIB) 2017-05-26 12:03:42 UTC
Okay, done
Comment 34 Xisco Faulí 2017-05-26 12:06:20 UTC
(In reply to Armin Le Grand (CIB) from comment #33)
> Okay, done

nice! thanks a lot. Could you please backport it to 5.4 and 5.3.4 ?
Comment 35 Commit Notification 2017-05-30 10:39:39 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-5-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c3c208e1fdfd60b95fc09ed48d9ee975bddb214d&h=libreoffice-5-4

tdf#106131 no global drag when anchor drag active

It will be available in 5.4.0.1.

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.
Comment 36 Commit Notification 2017-05-30 18:35:45 UTC
Armin Le Grand committed a patch related to this issue.
It has been pushed to "libreoffice-5-3":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=78f84a9a92f8dcd50747480d931f60c58b2344ec&h=libreoffice-5-3

tdf#106131 no global drag when anchor drag active

It will be available in 5.3.4.

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.
Comment 37 Xisco Faulí 2017-05-30 22:35:20 UTC
Verified in

Version: 5.5.0.0.alpha0+
Build ID: 36b1e6270bf2fbb333e2a69c4bb5931eba418289
CPU threads: 1; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@62-TDF, Branch:MASTER, Time: 2017-05-29_14:06:19
Locale: es-ES (es_ES); Calc: group