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
edit: *step2. left-click on the anchor symbol and drag it to the left side of the page
actually, it like just moving the line in the page, placing it somewhere and then pressing the left mouse button causes Writer to crash
*it looks like
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)?
Created attachment 131447 [details] This is what I meant by "height" of the mouse. You can see the cursor on the right.
Created attachment 131448 [details] Step 1. Select and drag, but make sure to have a preview like this one.
Created attachment 131449 [details] Step 2. Release the left mouse button and line should dissapear completely.
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 ?
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.
Created attachment 131452 [details] This is the crash report.
Created attachment 131453 [details] Line ends here after I reopen the document. Nothing is lost.
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.
Created attachment 131454 [details] The file I used to reproduce the bug.
I was able to reproduce the bug in a newly created file.
Hello Roman, it seems really difficult to follow the steps only with images. Could you please update a screencast instead?
Here is a link to a Youtube video about this bug, http://youtu.be/SuY4PhI1RaI?hd=1
Version must correspond to the oldest one for which the bug can be encountered.
Dear Roman, Thank you for making the video. However I can't reproduce it in Versión: 5.3.1.1 Id. de compilación: 72fee18f394a980128dc111963f2eefb05998eeb Subpr. de CPU: 1; SO: Windows 6.1; Repr. de IU: predet.; Motor de trazado: HarfBuzz; Configuración regional: es-ES (es_ES); Calc: group Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ? I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
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
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.
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
Created attachment 133443 [details] screencast
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
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
Created attachment 133444 [details] backtrace
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
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)
Could finally reproduce with screencast from comment 22. Taking a look...
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...
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.
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
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.
Okay, done
(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 ?
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.
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.
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