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.
User Profile Reset: No
Created attachment 156724 [details]
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 184.108.40.206, but it could also be inherited from OOo as bug129542
(In reply to Robert Großkopf from comment #4)
> Have tested it with LO 220.127.116.11, but it could also be inherited from OOo as
crashes with AOO 4.1.5
Crash stats suggest a recent regression
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
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: 18.104.22.168.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
This seems to have begun at the below commit.
Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one?
774506468555179a6274e6418058c48906fcc882 is the first bad commit
Author: Matthew Francis <email@example.com>
Date: Wed May 27 19:03:50 2015 +0800
Author: Caolán McNamara <firstname.lastname@example.org>
AuthorDate: Wed Feb 11 10:51:13 2015 +0000
Commit: Caolán McNamara <email@example.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":
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:
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. ***