Description: Table background colours that have been formatted are cleared or overridden when subsequent table formatting is applied and the background tab has been clicked but not edited. After some testing this is dependant on the state the dialogue is in when OK is pressed to apply the background colour and close the dialogue. The dialogue opens with the same tab active as when the OK was pressed. If the background tab was active (formatting the background) then next time the table properties dialogue opens, regardless of the cells selected, what ever shows by default in the background dialogue will be applied to all the selected cells. The same occurs if you open the table properties dialogue with another tab active and click the background tab. Without making any changes what shows will then overwrite what exists. Current settings are not retained until a change is made, like in the borders tab. Steps to Reproduce: 1.Create a 3x3 table in writer 2.Apply a background colour to the top middle cell and exit the dialogue with OK. 3.Select all cells and open the table properties dialogue. 4.Change the table border formatting and save. Actual Results: The background colour of the previously formatted cell is removed. Expected Results: The background formatting should remain. Background formatting should not be applied unless a change has been made in the background settings (as occurs with the boarders dialogue) Reproducible: Always User Profile Reset: No Additional Info: Also dependent on what cells have background colour formatted, the result is different if the complete top row was formatted with a background colour. Work around: 1.Change to the table properties tab before clicking OK. 2.Do not touch the background tab unless you wish to make a change to all the selected cells as what ever happens to show in the dialogue by default will then be applied to the selected cells.
Confirmed on Win 10 and linux, 6.1.6.3 and 6.2.4.2.
I confirm it with Version: 6.2.5.1 (x64) Build-ID: 9a940173fab1747f02322bc89779759d52b3a086 CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; VCL: win; Gebietsschema: de-DE (de_DE); UI-Sprache: de-DE Calc: threaded but not with Version: 6.4.0.0.alpha0+ (x64) Build ID: b170256fb6ebaf774b02b89835b19d9f3a1afb89 CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2019-06-07_03:30:35 Locale: de-DE (de_DE); UI-Language: en-US Calc: threaded Steve, could you please try to reproduce it with a master build from http://dev-builds.libreoffice.org/daily/master/ ? You can install it alongside the standard version. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the master build
Which master for windows? Win-x86_64@42/ - 2019-Jun-24 13:02 Win-x86_64@62-TDF/ 2019-Jun-21 01:09
[Automated Action] NeedInfo-To-Unconfirmed
(In reply to Steve Edmonds from comment #3) > Which master for windows? > Win-x86_64@42/ - 2019-Jun-24 13:02 > Win-x86_64@62-TDF/ 2019-Jun-21 01:09 https://dev-builds.libreoffice.org/daily/master/Win-x86_64@42/current/ (for Win 64bit)
The bug is not present in libo-master64~2019-06-24_11.33.05_LibreOfficeDev_6.4.0.0.alpha0_Win_x64 on win10.
(In reply to Steve Edmonds from comment #6) > The bug is not present in > libo-master64~2019-06-24_11.33.05_LibreOfficeDev_6.4.0.0.alpha0_Win_x64 on > win10. Seems, that is has been fixed in master => RESOLVED WORKSFORME