Description: If Table border colors are changed, the bottom border's color does not change on screen until the user clicks somewhere else; all the other borders are re-rendered in the new color immediately after OK is clicked. Please see attached screen shots shot #1: Immediately after clicking OK to change border color to red shot #2: After clicking in another paragraph not in the table Steps to Reproduce: 1. (in Writer) Table->Insert Table (take defaults to get 2x2 table) 2. Click in the table; then do Table->Select->Table 3. Table->Properties 4. Click the icon for all borders; set extra thick borders (still black); OK 5. Repeat steps 2-4 but just change the border color to red; click OK Actual Results: The borders other than the bottom border change to red. The bottom border remains black. Clicking *inside* the table does not change this, but as soon as you click outside the table, the bottom border color changes. Expected Results: All borders rendered in the new color Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 78d9d0d8dccb6fd8952435b8a13d525c7606f467 CPU threads: 12; OS: Linux 6.2; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Created attachment 189394 [details] Screenshot #1 (see description)
Created attachment 189395 [details] Screenshot #2
Created attachment 189396 [details] Screenshot #1 using timer (see description)
This may be relevant: I could not easily get a screenshot of the problem because it "fixed itself" the moment I clicked outside of LO to do the screenshot (I had to use the screenshot tool's timer mode to get it). So it is not "clicking" that finishes the rendering, but (perhaps) any mouse focus change. So this might be a problem with interacting with XOrg.
Thanks for the report, Jim. Reproduced in: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2ae9eb8be8d7eb9c3a72953a295d128b45639ea3 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded Also with gen/x11 VCL plugin. No repro in: Version: 7.6.1.1 (X86_64) / LibreOffice Community Build ID: c7cda394c5de06de37d8109c310df89a4d4c3a98 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded -> regression.
Hm I am getting different results between gen and gtk3 VCL plugins (and between release binaries vs bibisect binaries), so I ended up bibisecting for gtk3 only, with linux-64-6.4 repo to first bad commit 7e5766c677e820a05f3ea51489ffba0c004d9742 which point to core commit da2000648b852047ec9d865891539c28ada97730 which is a cherrypick of: commit d4ea54e18346a35590933dd1e8b83d1c12a741de author Miklos Vajna Mon Dec 16 21:01:13 2019 +0100 committer Miklos Vajna Tue Dec 17 09:03:25 2019 +0100 tdf#128567 sw: fix flicker of table selection highlight Reviewed-on: https://gerrit.libreoffice.org/85240 Miklos, can you please have a look?
Created attachment 189414 [details] test ODT To be completely clear, these are the steps I used for the bibisect: 1. Open attached ODT 2. Ctrl + A > context menu > Table Properties > Borders 3. Change border colour to Lime, click OK Result: parts of bottom and side borders don't update to new colour until next action.
Created attachment 189416 [details] Result with latest linux bibisect as of today Hm, I have trouble reproducing this. Here is what I tried: - git clone https://bibisect.libreoffice.org/linux-64-24.2 - that currently gives a binary of core.git commit d8dbf35c48698e49c527d740853ce4edc4f1afa9 (set java_websocket source as UTF-8, 2023-09-05) - SAL_USE_VCLPLUGIN=gtk3 instdir/program/soffice /path/to/tdf157125/orig.odt (which is attachment 189414 [details]) - used your repro steps - border color looks OK, I attach what I see. Do I miss something or was this fixed in the meantime? Thanks.
In the meantime I tried the original problem from the above commit and it seems this flicker doesn't happen when I revert it, so it would be probably OK to get rid of the change, but I would like to avoid a blind fix.
(In reply to Miklos Vajna from comment #9) > In the meantime I tried the original problem from the above commit and it > seems this flicker doesn't happen when I revert it, so it would be probably > OK to get rid of the change, but I would like to avoid a blind fix. Hm now I can't reproduce in oldest of linux-64-24.2 bibisect repo, not in a recent daily build: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 2902ab24ecc5ffbf4907ea83b2028508b9de6364 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: es-MX (en_AU.UTF-8); UI: en-US Calc: threaded But I still can reproduce in 7.6.2.1 and 7.5.7.1 releases. So difference between the bibisect/daily builds vs release builds? *shrugs*
Dear Jim Avera, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
Seems to have been fixed. WFM with 24.8 alpha