Created attachment 115492 [details] test document and backtrace In the attachment, move the frame anchor into the textbox and save. Result: Crash. 1. New Text Document. 2. Insert → Frame. 3. Type “This is a test.” into frame. 4. From toolbar, select a Rectangle from Basic Shapes and draw it. 5. Right click on rectangle and Add TextBox. 6. Type “test” into textbox. 7. Move rectangle anchor into frame paragraph. 8. Move frame anchor into textbox paragraph. 9. Save document. Result: Crash. Expected Result: It should not be possible to move the anchor into the textbox if the drawing object is anchored to the frame. If there is no text in the drawing object textbox then the document saves okay but when reopened the frame and drawing object have been lost. Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Confirmed crash with attachment 115492 [details] Win 7 Pro 64-bit, Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Locale: fi_FI
Version: 5.3.0.0.alpha0+ Build ID: d9cff00683d31fbd4b3c4c2d6afbe164f4a85d47 CPU Threads: 2; OS Version: Linux 3.16; UI Render: default; Locale: en-US (en_US.UTF-8); Calc: group Confirmed This is an insane set of steps that I suspect will affect exactly 1 person (maybe 2 ;) ). I suggest lowering to lowest or maybe just low. I know it's a crash but honestly, no one is going to hit this problem ever. Also, backtrace always appreciated for crashes.
The backtrace is in the zip file :)
Dear Gordo, To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Could not reproduce. (tried both with attached test document and with following the procedure described in the initial report.) Version: 6.3.3.1 (x64) Build ID: f41f4c7f9507aeca13cb9df51f34d80e8ba30a99 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win;
I can still repro with attachment 115492 [details]. To be clear on what I did (and this is even one step less than in the desc): I clicked the blue rectangle. I clicked'n'dragged its anchor into the frame that says "test". I saved the document. Arch Linux 64-bit Version: 6.4.0.0.alpha1+ Build ID: fa79e8df02a082cd4967bf7a1c61aa925dc7b101 CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 30 October 2019
(misunderstood the instructions before.) Can reproduce now both with: Version: 6.3.3.1 (x64) Build ID: f41f4c7f9507aeca13cb9df51f34d80e8ba30a99 CPU threads: 8; OS: Windows 10.0; UI render: default; VCL: win; and Version: 6.4.0.0.alpha1 (x64) Build ID: cc57df8f942f239d29cb575ea5a7cb01405db787 CPU threads: 8; OS: Windows 10.0 Build 18362; UI render: GL; VCL: win; Locale: en-US (en_DK); UI-Language: en-US Calc: CL
Here is link for the 6.3.3.1 crashreport from comment #7 http://crashreport.libreoffice.org/stats/crash_details/d5ac2352-5b03-4ca8-ba39-0a4f1bce6e00
Regression introduced by: author Miklos Vajna <vmiklos@collabora.co.uk> 2014-11-20 16:44:21 +0100 committer Miklos Vajna <vmiklos@collabora.co.uk> 2014-11-20 16:57:49 +0100 commit 01fc08c0b5c57fef8ad3755672f4266d85e849a5 (patch) tree 9f1a7f71281feae7e9be344a94371495f1a77338 parent 3d601cfa4b63580b5a0d18044b5792894d54089f (diff) fdo#85554 SwXShape: fix getting ZOrder property when doc contains TextBoxes https://cgit.freedesktop.org/libreoffice/core/commit/?id=01fc08c0b5c57fef8ad3755672f4266d85e849a5 Bisected with: bibisect-44max Adding Cc: to Miklos Vajna OTOH, Before https://cgit.freedesktop.org/libreoffice/core/commit/?id=9835a5823e0f559aabbc0e15ea126c82229c4bc7, 'test' frame was inside the blue shape, so fixing this issue would probably fix the crash
(In reply to Xisco Faulí from comment #9) > OTOH, Before > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=9835a5823e0f559aabbc0e15ea126c82229c4bc7, 'test' frame was inside the > blue shape, so fixing this issue would probably fix the crash @Miklos - maybe your project here is just to remove the crash, but in case you are willing to be more ambitious (or there is an obvious solution): In step 7 in STR, when the Shape anchor is moved into the Frame, then the position of the shape changes (while the shape's textbox does not change). Is that intended/expected? (seems wrong). Also possible to skip step 7, but follow step 8 (copy the frame anchor into the textbox), (even autosave is enough to make a crash). (note, that is the opposite of comment 6, which skips step 8) -- so there seem to be two ways to make the crash. Meanwhile, comment 2 seems relevant. Why would someone want to anchor a frame to a textbox? (maybe prohibiting that possibility would avoid one of the crashes?) But if you keep this possibility, then note that when the frame anchor is moved into the textbox, then the shape gets aligned in front of the textbox. (and strange things happen as you move the frame anchor in and out of the textbox).
We already have logic in place that you can't anchor a TextFrame into itself. (Or create such an "anchor cycle" in general.) A TextBox is a draw shape + TextFrame pair, but it's presented as a single object to the user. I'll extend the existing logic, so that you can't anchor a draw shape into a TextFrame in case the TextFrame and the draw shape forms the same TextBox. This not only should avoid the crash but I think also will fix the root cause here.
(In reply to Miklos Vajna from comment #11) > A TextBox is a draw shape + TextFrame pair, but it's presented as a single > object to the user. Question of clarification: Aren't there two meanings of TextBox here? 1. Insert->Textbox 2. Insert>Shape, select shape, right-click, Add Textbox. If yes, then does that mean that: - case 1: a draw shape (seen in Navigator) is inserted (simultaneously) with a TextFrame (not seen in Navigator, and no textframe boundaries shown). - case 2: a TextFrame is added to the shape (now the outlines of the frame are seen). (so even if menu item says "textbox", it is really a TextFrame?) If this interpretation is correct, then why can the shape (in case 1) be moved with its TextFrame following along, while there are various bug reports about case 2, where moving the shape does not also move the textframe (as expected) (e.g., the example here, when the Shape anchor is moved into the Frame, then the position of the shape changes (while the shape's textbox does not change). Just trying to understand the technical details better, because I try to triage the different bugs about unexpected behavior between TextFrame and "shape" (and cases where a frame is added to a shape/object). Thanks.
Yes, that's indeed the case. By the time we started to use TextBox in the Writer context (see https://vmiklos.hu/blog/textbox.html), nobody realized that TextBox is already used as a draw shape with a certain type. I guess you can always spell out "Writer TextBox" and "Draw TextBox" to be specific. (Till you don't realize the Draw problem, it seemed logical to have Writer TextBoxes next to existing TextFrames, sigh. :-) )
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/58fab0b920303e58d3ac3be28b22763970085f02 tdf#91219 sw: don't allow anchoring a shape+textbox into itself It will be available in 7.0.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.
Issue fixed in Version: 7.0.0.0.alpha0+ Build ID: c8d764b3f27c2bb0712745891b70630e94436317 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: gtk3; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded where it's no longer possible to anchor the shape into the textbox
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/0aaa48adee4c2f330f93bf1f1cf7e095c2e9768a tdf#91219 sw: don't allow anchoring a shape+textbox into itself It will be available in 6.4.2. 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.