Summary: | Table bottom border rendered wrong immediately after property change | ||
---|---|---|---|
Product: | LibreOffice | Reporter: | Jim Avera <jim.avera> |
Component: | Writer | Assignee: | Not Assigned <libreoffice-bugs> |
Status: | RESOLVED WORKSFORME | ||
Severity: | minor | CC: | stephane.guillou, telesto, vmiklos |
Priority: | low | Keywords: | bibisected, bisected, regression |
Version: | 6.4.0.3 release | ||
Hardware: | All | ||
OS: | All | ||
See Also: | https://bugs.documentfoundation.org/show_bug.cgi?id=128567 | ||
Whiteboard: | |||
Crash report or crash signature: | Regression By: | Miklos Vajna | |
Bug Depends on: | |||
Bug Blocks: | 103100 | ||
Attachments: |
Screenshot #1 (see description)
Screenshot #2 Screenshot #1 using timer (see description) test ODT Result with latest linux bibisect as of today |
Description
Jim Avera
2023-09-06 19:58:29 UTC
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 |