Bug 83523 - UI: Ruler background only changes according to application background setting *after* closing and restarting writer
Summary: UI: Ruler background only changes according to application background setting...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.3.1.2 release
Hardware: Other All
: medium minor
Assignee: Justin L
URL:
Whiteboard: BSA target:7.4.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Rulers
  Show dependency treegraph
 
Reported: 2014-09-05 09:11 UTC by retired
Modified: 2022-02-01 13:54 UTC (History)
8 users (show)

See Also:
Crash report or crash signature:
Regression By:


Attachments
new LO bakground yellow, rulers not updated yet (133.74 KB, image/jpeg)
2014-09-05 09:11 UTC, retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description retired 2014-09-05 09:11:54 UTC
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
Comment 1 Jacques Guilleron 2014-09-27 14:21:52 UTC
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
Comment 2 Matthew Francis 2015-01-21 07:22:27 UTC
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
Comment 3 Michael Weghorn 2015-01-30 22:55:09 UTC
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
Comment 4 Michael Weghorn 2015-01-30 22:56:29 UTC
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?
Comment 5 Michael Weghorn 2015-01-30 23:04:51 UTC
(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)...
Comment 6 Robinson Tryon (qubit) 2015-12-13 11:16:13 UTC Comment hidden (obsolete)
Comment 7 Xisco Faulí 2016-09-26 15:29:09 UTC
Adding Cc: to Michael Meeks
Comment 8 QA Administrators 2019-04-10 02:58:44 UTC Comment hidden (obsolete)
Comment 9 steve 2021-03-06 14:25:59 UTC
macOS 11.2.2
LO 7.1.1.2
persisting
Comment 10 Justin L 2022-01-21 16:20:25 UTC
It is a hack, but here is something.  http://gerrit.libreoffice.org/c/core/+/128733
Comment 11 Justin L 2022-01-24 05:21:34 UTC
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...
Comment 12 Commit Notification 2022-01-31 11:28:22 UTC
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.
Comment 13 steve 2022-02-01 12:59:08 UTC
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.
Comment 14 Justin L 2022-02-01 13:54:53 UTC
(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.