Description: Area color not properly removed (properly repainted) after changing style settings Steps to Reproduce: 1. Open the attached file 2. Sidebar -> Paragraph Styles 3. Modify default paragraph style 4. Disable area color (in tab) 5. Change fontsize to 10,5 Actual Results: Headings + Footer have still orange look (save and reload will fix) Expected Results: Shouldn't be so Reproducible: Always User Profile Reset: No Additional Info: Version: 7.1.0.0.alpha0+ (x64) Build ID: 43c60ce1ac7629a1462e927e6ff937469f58f743 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 162267 [details] Example file
Repro with Version: 6.0.6.0.0+ Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4 CPU threads: 4; OS: Windows 6.3; UI render: default; Locale: nl-NL (nl_NL); Calc: CL and with 4.4.7.2 but not with Versie 4.0.0.3 (Bouw-id: 7545bee9c2a0782548772a21bc84a9dcc583b89)
Confirm it Version: 6.4.4.2 Build ID: 3d775be2011f3886db32dfd395a6a6d1ca2630ff CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US Calc: threaded
Bibisected using repos bibisect-43max and bibisect-44max. After the following commit, no orange color is shown after opening the file: https://cgit.freedesktop.org/libreoffice/core/commit/?id=4a0b5e569d070c286daefb0fdfe45c0dd15d241c author Armin Le Grand <alg@apache.org> 2014-04-17 16:44:58 +0000 committer Miklos Vajna <vmiklos@collabora.co.uk> 2014-04-25 13:08:06 +0200 "i#124638 support for DrawingLayre FillStyle for GraphicFrames and ..." Then after this commit, the background color is back, but the behavior is already buggy: https://cgit.freedesktop.org/libreoffice/core/commit/?id=7d9bb549d498d6beed2c4050c402d09643febdfa author Armin Le Grand <alg@apache.org> 2014-06-02 15:00:50 +0000 committer Miklos Vajna <vmiklos@collabora.co.uk> 2014-07-01 13:30:09 +0200 "Related: #i124638# Second step of DrawingLayer FillAttributes..." These commits seem to deal with the affected functionality, but I can't verify that, and it might be an implementation error in that case, too. Marking as notBibisectable.
The last step of changing the fontsize is CRUCIAL to reproducing this. Just turning off the area colour by itself works fine. repro 7.2+ Footnotes is meant instead of footer. The ABC's in the Heading 1 paragraph style, and the footnote content remain with a yellow background. This suggests to me a layout bug.
Created attachment 170679 [details] 134204_red.odt: example document that doesn't use highlight. It looks like this is an inherited problem from OOo. Using this example avoids the complications of the changing background. I saw the same behaviour in bibisect-43all's LO 3.5 - which is as far back as I can test with Ubuntu 16.04.
Dear Telesto, 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 https://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://web.libera.chat/?settings=#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
repro 7.6+ (In reply to Justin L from comment #6) > 134204_red.odt: example document that doesn't use highlight. Steps to reproduce: 1.) open comment 6's attachment 170679 [details] 2.) Go to the default paragraph style dialog, Font Effects tab and change the red font color to something else. Then go to the font tab and change the font size. (the order doesn't matter - can change the font size first) --> result is that Heading 1 style text and the footnote text don't change. Doing them one at a time (instead of as a combination) has no problem. Using italic or bold along with font color has no problem. It seems to be specific to the font size in combination with one or more other attributes. I was easily able to reproduce this in a new document with just two paragraphs. One was with a Title paragraph style, and the other was default paragraph style.
repro 24.2+
repro 24.8+. Print preview or toggling View - Web are not workarounds.
(In reply to Justin L from comment #6) > It looks like this is an inherited problem from OOo. SAL_USE_VCLPLUGIN=gen opt/program/soffice lets me test bibisect-releases from Ubuntu 20.04, and I can reproduce in OOo 3.3 (oldest) I'm going to guess the problem is related to Headings and footnote specifying a fontsize override, but not a color override. [Footnotes have an indent override, but headings don't. Changing the default style to have a non-zero indent and changing the font color results in the Headings changing colour, but not the footnotes.]
Created attachment 195041 [details] 134204_fontCache.odt: simplified test document
I would say the problem is definitely in SwTextFormatColl::SwClientNotify. But just exactly how that should work will be rather tricky to understand. A likely wrong approach is https://gerrit.libreoffice.org/c/core/+/169724
The issue here comes from special handling for left/right/first margins, upper/lower spacing, and font sizes. If any of these had a hard coded value, it could veto notifying about the entire set of changes.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cdf2681d996286953dffa8a033de1b947ae23768 tdf#134204 sw: notify when para style inherited a new property It will be available in 25.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c9a96f272430a8ba5a29207d3365354c82d08e60 NFC tdf#134204: ensure style modify signaled if parent changed It will be available in 25.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/cafb0235fde21065770fd34a36b97c738c4174b0 related tdf#134204 : notify change unless all properties are handled #1 It will be available in 25.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/f8c68d3499512a7f559fa990ec8a1648e3a7e5d5 related tdf#134204 : notify change unless all properties are handled #2 It will be available in 25.2.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.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/49763e1fc4ec4308d52a3d578246ecc4ad3108b2 tdf#134204 : notify change unless all properties are handled #3 It will be available in 25.2.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.