Bug 132312 - Parts of Control Properties or Form Properties dialogs turn black (Skia) or white (OpenGL) when changing some options
Summary: Parts of Control Properties or Form Properties dialogs turn black (Skia) or w...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
7.0.0.0.alpha0+
Hardware: All Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 160132 (view as bug list)
Depends on:
Blocks: Form-Controls Skia
  Show dependency treegraph
 
Reported: 2020-04-21 20:43 UTC by Telesto
Modified: 2024-12-29 21:54 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2020-04-21 20:43:11 UTC
Description:
UI Checkbox properties window black (Skia) white (OpenGL)

Steps to Reproduce:
1. Open Writer
2. Insert a checkbox (Form)
3. Double click it -> Checkbox Control
4. Scroll down to tristate & change it -> Dialog black/or white

Actual Results:
Dialog not properly rendered

Expected Results:
Proper layout


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 7.0.0.0.alpha0+ (x64)Build ID: 8c8b3a4f83f67882b284ddc3b3fe10d3fe6dedf4CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: GL; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-USCalc: CL
Comment 1 Durgapriyanka 2020-04-21 22:00:24 UTC
Thank you for reporting the bug. I can confirm the bug present in

Version: 6.4.0.0.alpha1+ (x86)
Build ID: ec7374ff84c71edfbb30d6e4dc5b486b6df7107f
CPU threads: 2; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2019-11-10_21:37:30
Locale: en-US (en_US); UI-Language: en-US
Calc: threaded
Comment 2 QA Administrators 2022-04-23 03:51:36 UTC Comment hidden (obsolete)
Comment 3 Telesto 2022-04-23 06:52:32 UTC
Still present
Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 4659fc2f0a7223a89446edff0b77e58758b5edf5
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL
Comment 4 Kira Tubo 2023-10-13 07:01:49 UTC
Reproduced in daily master build:

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 1ec2e39cf4d5fe0a592bc783fd8bcdc4345c8cbd
CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded

Version: 7.0.3.1 (x64)
Build ID: d7547858d014d4cf69878db179d326fc3483e082
CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 5 Kira Tubo 2023-10-13 07:12:48 UTC
Bibisected win64-7.0. Added Caolán McNamara to cc. 

Regression introduced in commit: https://git.libreoffice.org/core/+/1efeb17837c22499f00299c033ae59ba3910f7d7

---------------------

commit 1efeb17837c22499f00299c033ae59ba3910f7d7	[log]
author	Caolán McNamara <caolanm@redhat.com>	Mon Nov 04 13:06:04 2019 +0000
committer	Caolán McNamara <caolanm@redhat.com>	Mon Dec 09 13:28:35 2019 +0100
tree a8db0b758e942b3b14fba26129dc51a95ff5c10c
parent 4da3e0a0e5b2260c26186890724978bfd00f796c [diff]

---------------------- f7cdd32887fa614c27fc4ee36e977bc85d0d268f is the first bad commit
commit f7cdd32887fa614c27fc4ee36e977bc85d0d268f
Author: Norbert Thiebaud <nthiebaud@gmail.com>
Date:   Mon Dec 9 04:57:38 2019 -0800

    source 1efeb17837c22499f00299c033ae59ba3910f7d7
Comment 6 Stéphane Guillou (stragu) 2024-03-26 11:51:47 UTC
*** Bug 160132 has been marked as a duplicate of this bug. ***
Comment 7 Stéphane Guillou (stragu) 2024-03-26 11:56:20 UTC
Coming from duplicate bug 160132:

Also seen e.g. in a Base form, with a Combo Box control, changing "Control Properties > Data > Type of list contents" from "sql" to "table".
Also reproduced with the Form Properties dialog (changing the "Content Type"), and for a List Box control.

Hovering over fields refreshes them, or changing tabs, refreshes the view.

- Version: 7.5.0.3 (X86_64)
- Version: 24.2.1.2 (X86_64)
- Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 26f7313f724921a9c6086e6c2a93fbe1c48635fa
CPU threads: 4; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

Not reproduced with Skia off:

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
CPU threads: 4; OS: Windows 10.0 Build 22631; UI render: default; VCL: win

Nor on Linux:

Version: 24.2.2.1 (X86_64) / LibreOffice Community
CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: x11

...but I did notice a change in item spacing when changing the "type of list content" value, even though the items don't change.
Comment 8 Caolán McNamara 2024-12-29 21:54:43 UTC
This one is odd, not reproducible on Linux with gen and skia enabled, but can be on Windows.

Debugging into it, at OBrowserListBox::valueChanged,

m_pLineListener->Commit(rLine.pLine->GetEntryName(), impl_getControlAsPropertyValue(rLine));

seems to be relevant to the oddity.

wrt. "I did notice a change in item spacing when changing the "type of list content" value, even though the items don't change." I see that the last row, the "List Content" row changes from a plain Edit to an Edit + Button with "..." in it, and presumably the button is taller than the Edit, and presumably the rows are set to be the same height, so toggling "Type of list contents" ends up toggling the height of all rows. But that's probably isn't a trigger for the main strange drawing issue.