Description: Footnote styles not properly applied: always or text area or footnote area but not both at the same time Steps to Reproduce: 1. Open the attached file 2. Tools -> Footnotes and endnotes 3. Strong emphasis for "Text Area" and "Footnote area" Actual Results: Emphasis for Text area only Expected Results: Both area's Reproducible: Always User Profile Reset: No Additional Info: Version: 7.2.0.0.alpha0+ (x64) Build ID: f2171af6ce3516598d9f8bac8294025a21a5b1a2 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Created attachment 168958 [details] Example file
Also in Version: 6.2.4.0.0+ Build ID: 5c5eab3522368d6baa7ab6ef1b6c9f5eaaab4fad CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Still OK in Versie: 6.0.4.1 Build ID: a63363f6506b8bdc5222481ce79ef33b2d13c741 CPU-threads: 4; Besturingssysteem: Windows 6.3; UI-render: GL; Locale: nl-NL (nl_NL); Calc: CL
Created attachment 168959 [details] Example file With bold enabled used for bibisect
Created attachment 168960 [details] Bibisect log Bibisected to: author Bjoern Michaelsen <bjoern.michaelsen@libreoffice.org> 2018-11-10 20:22:50 +0100 committer Xisco Faulí <xiscofauli@libreoffice.org> 2018-11-27 21:14:02 +0100 commit 912c1584cbdb5eaedb079755df1150b95e8f7329 (patch) tree ca64cc869709396cb912ff5ff9bbd9418b2c1dd1 parent 4fae59d27c29011b1bcd6e9db8c43e38dfe50c82 (diff) tdf#120115: Dont crash on Footnote/Table undo/redo brown paperbag commit: - for one, we only want to use the anchor format when we dont have another one, not the other way around - also we want to update the anchor format (not the char format) when it tells us so. - finally, keep the selected Char and AnchorFormat in Sync between SwEndnoteInfo and the underlying DocumentStylePoolManager https://cgit.freedesktop.org/libreoffice/core/commit/?id=912c1584cbdb5eaedb079755df1150b95e8f7329
@MWT In search for someone who could confirm this.. it's straight forward bug.. which should be present; and it's already present for way to long :-( How can this go unnoticed..
Confirm in Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 1a167625314bf36b735176ed488e6ba9b5e9b675 CPU threads: 8; OS: Windows 10.0 Build 21292; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
Adding CC: to Bjoern Michaelsen
*** This bug has been marked as a duplicate of bug 123027 ***