Description: On pc Debian x86-64 with master sources updated today, I got a crash when using changing Anchor Page to Anchor character. Steps to Reproduce: 1. Open https://bugs.documentfoundation.org/attachment.cgi?id=156698 (tdf#129524) 2. Set design-mode of the form to "yes". 3. Mark the listfield and set Anchor > To Character. Actual Results: Crash Expected Results: No crash Reproducible: Always User Profile Reset: No Additional Info:
Created attachment 156724 [details] Valgrind trace
Created attachment 156725 [details] bt with debug symbols
Could confirm the buggy behavior. It's impossible to set a form control into a page header.
Have tested it with LO 6.3.4.2, but it could also be inherited from OOo as bug129542
(In reply to Robert Großkopf from comment #4) > Have tested it with LO 6.3.4.2, but it could also be inherited from OOo as > bug129542 crashes with AOO 4.1.5
Crash stats suggest a recent regression https://crashreport.libreoffice.org/stats/signature/SwFrame::IsVertical() No repro Versie: 4.4.7.2 Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600 Locale: nl_NL
On pc Debian x86-64 with master sources updated today, I gave a new try and don't reproduce the crash anymore with "To Character". However, I got a crash with "As Character". Could someone confirm this?
Yes and no. Setting it paragraph followed by to character = crash. But no crash setting it to character the first time. Didn't check reselecting as to character a second time
(In reply to Julien Nabet from comment #7) > On pc Debian x86-64 with master sources updated today, I gave a new try and > don't reproduce the crash anymore with "To Character". > > However, I got a crash with "As Character". > > Could someone confirm this? I can confirm with Version: 7.1.0.0.alpha0+ Build ID: 6ad2f463784a24c566477cdd60ae729651bb8564 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: x11 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
This seems to have begun at the below commit. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks 774506468555179a6274e6418058c48906fcc882 is the first bad commit commit 774506468555179a6274e6418058c48906fcc882 Author: Matthew Francis <mjay.francis@gmail.com> Date: Wed May 27 19:03:50 2015 +0800 source-hash-0a6a151c4b7c78a363fb64598fbda39db4f42d07 commit 0a6a151c4b7c78a363fb64598fbda39db4f42d07 Author: Caolán McNamara <caolanm@redhat.com> AuthorDate: Wed Feb 11 10:51:13 2015 +0000 Commit: Caolán McNamara <caolanm@redhat.com> CommitDate: Wed Feb 11 12:00:03 2015 +0000 Related: tdf#70062 keep drawing anchor objects sorted take attachment from tdf#70062, ungroup the bottom pair, anchor as char the left one, anchor as char the right one asserts with debugging stl on unsorted container
I suspect this has ~always been a bit broken. IIRC the story is something like that drawing objects at one point could only appear in the first instance of a header. So after a page break the drawing objects were missing on the next view of the header. Then the feature was implemented so they could appear on all instances of the header. Looks like control forms are left out of that support. In this document for example the form control only appears in the first header instance, its not shown on the other ones. (maybe it shouldn't have been possible to add a form control into a header, you need to fiddle around with it a bit to force it anchored to something in the header) The change anchor unsets the form control old anchor, but the code disallows it to anchor into a header/footer so it ends up with no anchor which eventually crashes, e.g. on changing its anchor again. https://gerrit.libreoffice.org/c/core/+/100686 would allow it to anchor to the first instance of the header (as it initially is imported as) on changing anchor
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6e0c7591ab86a893be85087d3caee0328e9411dd tdf#129542 the control is already anchored to header/footer content It will be available in 7.1.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.
fixed in master, reluctant to backport for now. Forms controls in header/footers are presumably rare
Thank you Caolán for the fix, I can confirm it works.(In reply to Caolán McNamara from comment #13) > fixed in master, reluctant to backport for now. Forms controls in > header/footers are presumably rare Thank you Caolán for the fix, I can confirm it works. I agree with you no need to backport it since a form in header is rather unexpected.
*** Bug 121541 has been marked as a duplicate of this bug. ***