Description: If I remember correctly, this bug didn’t exist in previous versions. Steps to Reproduce: 1. Type aa in A1, then come back to A1. 2. From the toolbar, set the font colour to (let’s say) automatic and the background to none. 3. Start typing something in A2 or wherever else. Actual Results: As soon as you start typing, the toolbar colours resets to propose the default red font and yellow background. Therefore, if you want to apply the same settings as in A1, you have to reselect your colours from the drop‐down list rather than just press the colour button to reuse the previous choice. Let’s add that if you fiddle with other functions in the meantime, like play with the mouse, the menus, the arrow keys, these buttons won’t reset. They only reset if you start typing somewhere. For example, if you don’t type but want to apply your colour choice to another cell, you can reuse your toolbar button setting. But don’t start typing because your button colour choice is lost. Expected Results: Don’t unnecessarily reset the choice of colours the user made. Be consistent and don’t change the user choices in some cases but not others. Reproducible: Always User Profile Reset: No Additional Info: There might be other settings that are reset, but I mainly use those two ones.
“Whiteboard: QA:needsComment” What other comment is needed from the reporter? I can’t find an explanation in the Whiteboard page. The steps are explained. The bug rather needs someone to fix it.
(In reply to maison from comment #1) > “Whiteboard: QA:needsComment” > What other comment is needed from the reporter? I can’t find an explanation > in the Whiteboard page. The steps are explained. The bug rather needs > someone to fix it. QA:needsComment is for QA, not for the reporter.
Hello Maison. Thank you for reporting the bug. I was not able to reproduce the bug using the following versions: Version: 7.6.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: a834bbad8295cba0ca88a91a524aad48640271ec CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded Kind Regards
@maison, Please open LO, menu help > about. Click the icon in the middle of the dialog. Then come back to the bug report and add a comment. Pressing [CTRL]+[V] should paste the info in the comment.
I’ve just updated to this today, but the bug is still there. Version: 7.5.2.2 (X86_64) / LibreOffice Community Build ID: 53bb9681a964705cf672590721dbc85eb4d0c3a2 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: fr-FR (fr_FR); UI: fr-FR Calc: threaded
(In reply to maison from comment #5) > CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Maybe this happens only in Windows Seven (?).
Nope, otherwise I would have mentioned. Windows 10 also.
(In reply to maison from comment #7) > Nope, otherwise I would have mentioned. Windows 10 also. I just raised the potential question, according to the info you posted in comment 5. It was an attempt to try to narrow down the situation so as to replicate the issue, by someone with a similar context. If you can replicate the problem under Windows 10, please paste here that info. And if you test this under Windows 10 and you cannot replicate this problem, please add such details too. BTW, which type of toolbar/UI are you using? Is it the standard UI, or some other? (Menu View > User Interface) Have you tried menu Help > Restart in Safe Mode? (I would suggest a backup of your profile before resetting to factory default.)
So, it’s not the profile. It’s the one toolbar interface that resets the colours and maybe who knows what other settings.
(In reply to maison from comment #9) > So, it’s not the profile. It’s the one toolbar interface that resets the > colours and maybe who knows what other settings. Again, have you tested different UI variants (menu View > UI Interface)? Does it happen with all of them? Or only with some of them? Which ones? You still haven’t pasted the info when running this under Windows 10 (according to your comment 7), and whether you can replicate the exact same behavior, or there is any difference there.
ady, I don’t understand why you are asking for things again and again. What brought the pasted text of what I have entered yet? I’m not logged on this website from Win 10 and it’s worthless to just copy things from one to the other without drawing a conclusion from the previous one. Should I keep testing more and more? I gave a reproducible way. Can you rather confirm and take the bug for fixing? Where is its origin? Then we can start testing according to where it originates rather than keep shooting in the air.
(In reply to maison from comment #11) > ady, I don’t understand why you are asking for things again and again. Because you answered that you can also reproduce the behavior in win10, not just in win7, but did not provide the info I requested previously, and then you mentioned the standard toolbar, but didn't answer what I asked about other UIs. I am trying to narrow down the context, because I was not able to reproduce it. With additional details (whether from your own tests, or from other users), we might be able to find out in which context or which conditions are necessary to trigger the problem. Until this moment, I was not able to. For example, if this happens when using the standard toolbar, but not with Notebook (or some other) UI, then we can retest under that particular UI. Or perhaps this happens under a certain locale, but not with English (US), as another random example. If, instead of testing different variables, you are happy to wait until someone by chance finds this report and, by chance, is able to replicate it, that's fine, let's wait. There might be some setting in Accessibility, or in View, or... that changes the behavior. Yes, it might sound as guesses, but it is not completely uneducated random guess. Maybe someone else might have a better idea on how to trigger the reported behavior.
It’s not the standard two‐line interface, but the single toolbar interface. I started a new profile, but the bug doesn’t happen. I set the single toolbar interface and then the bug is triggered.
(In reply to maison from comment #13) > I set the single toolbar interface and then the bug is triggered. Repro in 7.6 alpha, not in 7.4.6. > regression.
This seems to have begun at the below commit in bibisect repository/OS linux-64-7.5. Adding Cc: to Maxim Monastirsky ; Could you possibly take a look at this one? Thanks 502feab2611d6ffc071d2e0fa40865fb9ccd5504 is the first bad commit commit 502feab2611d6ffc071d2e0fa40865fb9ccd5504 Author: Jenkins Build User <tdf@pollux.tdf> Date: Fri Jun 24 02:36:28 2022 +0200 source 9bc1ffa2153d2474b023e0860d3c9c68ee18727b 135591: tdf#125040 Make single mode toolbar context aware | https://gerrit.libreoffice.org/c/core/+/135591
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/8ffb8e164d9d350a1b9887d0a75e0a82892008ee tdf#154270 Sync toolbar button recent colors It will be available in 24.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.
*** Bug 150785 has been marked as a duplicate of this bug. ***
*** Bug 122003 has been marked as a duplicate of this bug. ***
*** Bug 139803 has been marked as a duplicate of this bug. ***
*** Bug 113433 has been marked as a duplicate of this bug. ***
*** Bug 82438 has been marked as a duplicate of this bug. ***
*** Bug 154102 has been marked as a duplicate of this bug. ***
*** Bug 139209 has been marked as a duplicate of this bug. ***
*** Bug 90852 has been marked as a duplicate of this bug. ***
*** Bug 142962 has been marked as a duplicate of this bug. ***
*** Bug 140097 has been marked as a duplicate of this bug. ***
*** Bug 146119 has been marked as a duplicate of this bug. ***
Works as expected as of: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 81726f5af5fda25f0d92ffc8458d7f24eb16f408 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: CL threaded Probably some back-port / cherry-pick would be desirable?
Not yet in 7.6.0
Should we add here or something else that the Single Toolbar UI forgets to update when you go in Print Preview?
*** Bug 156803 has been marked as a duplicate of this bug. ***
Verified fixed in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: d88779fc86385dde1215fd28b78a69eacc6b4f97 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Maxim, I understand that this commit is wider-ranging than just a fix for the regression introduced in 7.5, but do you think it is OK to get it cherrypicked for 7.6?
(In reply to Stéphane Guillou (stragu) from comment #32) > Verified fixed in: > > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: d88779fc86385dde1215fd28b78a69eacc6b4f97 > CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 > Locale: en-AU (en_AU.UTF-8); UI: en-US > Calc: threaded > > Maxim, I understand that this commit is wider-ranging than just a fix for > the regression introduced in 7.5, but do you think it is OK to get it > cherrypicked for 7.6? Done -> https://gerrit.libreoffice.org/c/core/+/156519
Thanks for the cherrypick Xisco, and thanks for the big fix, Maxim! :) (In reply to maison from comment #30) > Should we add here or something else that the Single Toolbar UI forgets to > update when you go in Print Preview? I don't see that in 7.5.5.2. If you can still reproduce, please report in a new ticket. Thanks!
If you use the default interface, you get a special toolbar in the Print preview. If you use the one line interface (maybe something else), it stays the same in the Print preview, but it has nothing to do there because it’s unadapted.
Maxim Monastirsky committed a patch related to this issue. It has been pushed to "libreoffice-7-6": https://git.libreoffice.org/core/commit/1345619e0b3c2825c2ae50ada2c209d4ad8461ad tdf#154270 Sync toolbar button recent colors It will be available in 7.6.2. 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.