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: NEW
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: Not Assigned
URL:
Whiteboard: BSA
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Rulers
  Show dependency treegraph
 
Reported: 2014-09-05 09:11 UTC by retired
Modified: 2019-04-10 02:58 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


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
** 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