Download it now!
Bug 91219 - FILESAVE: Crash when anchoring a shape with a textbox to a frame that is anchored to that shape
Summary: FILESAVE: Crash when anchoring a shape with a textbox to a frame that is anc...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.3.2 release
Hardware: All All
: high major
Assignee: Miklos Vajna
URL:
Whiteboard: target:7.0.0 target:6.4.2
Keywords: bibisected, bisected, haveBacktrace, regression
Depends on:
Blocks: Textbox Frame
  Show dependency treegraph
 
Reported: 2015-05-11 13:09 UTC by Gordo
Modified: 2020-02-27 10:40 UTC (History)
4 users (show)

See Also:
Crash report or crash signature: ["write_uInt16s_FromOUString(SvStream &,rtl::OUString const &,unsigned int)"]


Attachments
test document and backtrace (9.70 KB, application/zip)
2015-05-11 13:09 UTC, Gordo
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gordo 2015-05-11 13:09:21 UTC
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
Comment 1 Buovjaga 2015-05-15 15:44:25 UTC
Confirmed crash with attachment 115492 [details]

Win 7 Pro 64-bit, Version: 4.4.3.2
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16
Locale: fi_FI
Comment 2 QA Administrators 2016-09-17 03:54:05 UTC
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.
Comment 3 Buovjaga 2016-09-17 19:41:20 UTC
The backtrace is in the zip file :)
Comment 4 QA Administrators 2019-06-15 02:58:55 UTC Comment hidden (obsolete)
Comment 5 sdc.blanco 2019-10-29 23:44:23 UTC
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;
Comment 6 Buovjaga 2019-10-30 20:16:11 UTC
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
Comment 7 sdc.blanco 2019-10-30 21:45:27 UTC
(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
Comment 8 sdc.blanco 2019-10-30 22:12:20 UTC
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
Comment 9 Xisco Faulí 2019-11-06 11:51:03 UTC
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
Comment 10 sdc.blanco 2020-02-21 00:17:20 UTC
(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).
Comment 11 Miklos Vajna 2020-02-21 08:48:49 UTC
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.
Comment 12 sdc.blanco 2020-02-21 10:28:31 UTC
(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.
Comment 13 Miklos Vajna 2020-02-21 10:32:22 UTC
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. :-) )
Comment 14 Commit Notification 2020-02-25 08:02:16 UTC
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.
Comment 15 Xisco Faulí 2020-02-26 11:36:44 UTC
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
Comment 16 Commit Notification 2020-02-27 10:40:39 UTC
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.