Created attachment 105790 [details] new LO bakground yellow, rulers not updated yet Problem description: Ruler background only changes according to application background setting *after* closing and restarting writer. Steps to reproduce: 1. open writer 2. open LO settings > LO > Appearance > Application Background, change color Current behavior: only background color changes but ruler background color stays at the same color until writer is restarted. than the ruler color matches the new background color. Expected behavior: Background color *and* ruler background color should change. no restart of writer should be required. if it works for the application background, it can and should work for the ruler background as well. Operating System: All Version: 4.3.1.2 release
Hi Foss, That's right. I reproduce with LO 4.3.1.2 Build ID: f9b3ad49d92181b0a1fe7e76f785a2c2cd0847d3 windows 7 Home Premium. Set status to NEW. rega
Up to at least 4.3.0.4, the background to the rulers wasn't affected by this setting at all. On that basis there should be a commit that can be found which changed the behaviour Setting: Keywords -> regression Whiteboard -> bibisectRequest
If I understood correctly, the goal of bibisecting was to find the commit range from which on the ruler background is also affected by this setting. In this case, the bibisect result is the following: There are only 'skip'ped commits left to test. The first bad commit could be any of: cd207063d6706c302b4d6ebe44c0ea9fcb29bd47 8fa9ed399be4ea4ac5294efeae7dd5798f9ae6e2 We cannot bisect more! ------ # bad: [4a3091e95fa263d3e2dd81e56e83996f0bb12287] source-hash-2b5b04e1e62914bf0902dfd7943cdc44499c47a6 # good: [812c4a492375ac47b3557fbb32f5637fc89d60d9] source-hash-dea4a3b9d7182700abeb4dc756a24a9e8dea8474 git bisect start 'latest' 'oldest' # good: [5d0dfb8e62ae61a240f8313c594d4560e7c8e048] source-hash-0c6cd530de13f80795881f61064f1bf1dcc4ea81 git bisect good 5d0dfb8e62ae61a240f8313c594d4560e7c8e048 # bad: [7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5] source-hash-f93ce4f7eb90093d0ea3115d0a1c614612676dbd git bisect bad 7dfacd0b8bd828331d74c0f79de6e8924bc4e6a5 # good: [1a63057f6378db7c6b8af1171b7b140f7583f246] source-hash-59f84b4a2c082382767f12e0c7a06a3f0b52e721 git bisect good 1a63057f6378db7c6b8af1171b7b140f7583f246 # bad: [2fdc98d4cfbffea5b33224bd2106aeb3b74b84a7] source-hash-d4a8fa7db0ed4faae00408fbda2352379774cfc0 git bisect bad 2fdc98d4cfbffea5b33224bd2106aeb3b74b84a7 # bad: [98aed8015d7af3a5a132192a34a4b11d8125a220] source-hash-91573182c8474297ef893f98bb04e830f3095cc2 git bisect bad 98aed8015d7af3a5a132192a34a4b11d8125a220 # bad: [ffdd7450b8a7b29a46647c85dd6d3291b1b96003] source-hash-a3fc7f20089062afa4f778e70ba8be84032a30a7 git bisect bad ffdd7450b8a7b29a46647c85dd6d3291b1b96003 # skip: [cd207063d6706c302b4d6ebe44c0ea9fcb29bd47] source-hash-057613c6864204ac5c09260e93a8f14cc9768b90 git bisect skip cd207063d6706c302b4d6ebe44c0ea9fcb29bd47 # bad: [8fa9ed399be4ea4ac5294efeae7dd5798f9ae6e2] source-hash-4a1a94dff6a76d70ee72c6c840a24953eca0a9f0 git bisect bad 8fa9ed399be4ea4ac5294efeae7dd5798f9ae6e2 # good: [2db4c8167c9eb9e581214397fb612cbe6c3978d7] source-hash-2e0561c9962e1205b68ae0c9971c4df7b141f535 git bisect good 2db4c8167c9eb9e581214397fb612cbe6c3978d7 # only skipped commits left to test # possible first bad commit: [8fa9ed399be4ea4ac5294efeae7dd5798f9ae6e2] source-hash-4a1a94dff6a76d70ee72c6c840a24953eca0a9f0 # possible first bad commit: [cd207063d6706c302b4d6ebe44c0ea9fcb29bd47] source-hash-057613c6864204ac5c09260e93a8f14cc9768b90
And the respective commit most certainly is this one: commit b0cdd038ee192dcc0d83182a33fc8c0242ceb1dd Author: Michael Meeks <michael.meeks@collabora.com> Date: Thu Jul 24 14:24:25 2014 -0400 fdo#51534 - rulers should have app-background by default (apparently). Change-Id: I981febb02074ed323732ef7c19e89f1e946604f1 @Michael: Could you possibly have a look at this?
(In reply to Michael Weghorn from comment #4) > And the respective commit most certainly is this one: > > commit b0cdd038ee192dcc0d83182a33fc8c0242ceb1dd > Author: Michael Meeks <michael.meeks@collabora.com> > Date: Thu Jul 24 14:24:25 2014 -0400 > > fdo#51534 - rulers should have app-background by default (apparently). > > Change-Id: I981febb02074ed323732ef7c19e89f1e946604f1 > > > @Michael: Could you possibly have a look at this? Well, in fact I should have looked at tdf#51534 before. It is already documented there that Writer has to be closed and re-opened again. Actually, this bug here has been opened as a consequence of tdf#51534 (s. comment 17 there)...
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]
Adding Cc: to Michael Meeks
** Please read this message in its entirety before responding ** 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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
macOS 11.2.2 LO 7.1.1.2 persisting
It is a hack, but here is something. http://gerrit.libreoffice.org/c/core/+/128733
Bug 132788 seems slightly related, doing something similar one step higher in a more generic function. At least it shows that monkeying with this code can easily lead to other problems. At least my hacking is in good company...
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2174b56ffb5817e42c8b4f6891214fcb67c55b30 tdf#83523 ruler: Invalidate full ruler rect on app bg change It will be available in 7.4.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.
Menu has changed LO > Settings > LO > Application Colors > Application Background Changing that and hitting "OK" instantly changes the ruler background. However there is a remaining problem: when hitting "Apply" instead of "OK" the new color is not applied to ruler. @Justin: are you willing to look into that as well? I could file a followup bug, but maybe this can be tackled here as well? Not yet setting to verified until I have your feedback on this.
(In reply to steve from comment #13) > However there is a remaining problem: when hitting "Apply" instead of "OK" > the new color is not applied to ruler. That is a wider scope (since none of my current debugging code for investigating this bug gives any indication where the invalidation needs to happen). I notice that it affects the little widget on the far right as well - something that even before my code already updated itself on OK. So it seems like the entire ruler is not invalidated until an OK. If it was me, I wouldn't even bother to report a bug about something so trivial. After all, this one took 8 years to fix, "regression" and all. But yeah, if you want it fixed, then file a separate bug report.