Created attachment 187644 [details] Open the form for editing and have a look at the background of the form controls. Open the attached document with Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: b76a3bdc996f275f9d615b32d6ab89d533a7505c CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Open the form for editing, not for input data. Seems all controls are set with transparent background. Click on a form control. Background is set to "white" for 3 fields, is set to yellow for the first control (ID). There are many more bugs in this form, created in LO 7.6.0.0.alpha1 on OpenSUSE 15.4 64bit rpm Linux. This is the first.
Confirm with Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 845054aa25b7cba1daa1ff30b142d549027299bd CPU threads: 4; OS: Linux 5.19; UI render: default; VCL: gtk3 Locale: cs-CZ (cs_CZ.UTF-8); UI: en-US Calc: threaded
This seems to have begun at the below commit in bibisect repository/OS XXXX. Adding Cc: to Caolán McNamara ; Could you possibly take a look at this one? Thanks dede51c596ae1f4cc5234d51487ad5e6d0f950fe is the first bad commit commit dede51c596ae1f4cc5234d51487ad5e6d0f950fe Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu May 4 17:00:09 2023 +0200 source 96a403b9b12fbea4cd1d72c55597dd64023de465 151356: Resolves: tdf#155029 set StandardStyles before updateFromModel | https://gerrit.libreoffice.org/c/core/+/151356
I tested this and confirm that 1st is yellow. But is we change it and save and change back to Default, it is white. Seems like minor issue, anyway, I remove Caolan from Regression by.
(In reply to Timur from comment #3) > I tested this and confirm that 1st is yellow. > But is we change it and save and change back to Default, it is white. > Seems like minor issue, anyway, I remove Caolan from Regression by. Seems you haven't understand the buggy behavior. The first control should be with yellow background. Other controls should be with white backgrounds. Open the form for editing and all form controls won't have any background. Changing of the background will never been shown while editing the form and this is the bug. And again: For persons, who create forms, this isn't a minor bug. And this isn't the only bug in creating (and using) forms since LO 7.5. A second bug you could see when opening the form for input data: Multiline fields aren't shown with a background also while input data, so this fields are unusable any more (here with KDE).
I maybe did not understand. Best way to report bug is to write Steps and Experienced and Expected behavior, so that it is clear later. Here you say "The first control should be with yellow background. " - why? It opens yellow so you expect yellow in Edit? But it is "Default color" not yellow? And if someone from QA changes field, do not change again, because you think it is important - just explain and call someone else to evaluate, OK?
(In reply to Timur from comment #5) > I maybe did not understand. Best way to report bug is to write Steps and > Experienced and Expected behavior, so that it is clear later. Please read the bug description: Open the form for editing, not for input data. OK, there might be somebody, who didn't ever used Base and want to have a look at Base bugs: Right mouse click on the form → context menu → Edit… You will see form controls, which all seem to be transparent. No background. Now mark one of the transparent controls (Ctrl + left mouse click). Right mouseclick → Control Properties → General Have a look at the Background Color. For 3 fields you could see "White", one field is set to "Light Yellow 4". None of this colors will be shown in design mode any more. This is the bug: Design doesn't show the background colors. It doesn't show the default color "White", it doesn't show any other color as chosen. > > Here you say "The first control should be with yellow background. " - why? Because this is the design for the form. In my forms, for example, all fields, which are write protected, will be shown with "Light Yellow 4". And I expect, if I chose this color, it will be shown in editing mode. > > And if someone from QA changes field, do not change again, because you think > it is important - just explain and call someone else to evaluate, OK? Maybe you don't know: I'm also "from QA", but special Base - and this since 2011. I'm the author of the German Base-Handbuch. It is very frustating for a Base user to see the many bugs in Base, which are ignored, where nobody is interested in… And this is the next step I see: We set the bugs in Base to minor bugs.
Created attachment 190609 [details] Form in LO 7.4, 75, 24.2 > Have a look at the Background Color. For 3 fields you could see "White", one field is set to "Light Yellow 4". That was confusing. Because in all versions I tested, n Edit mode Background Color is shown as Default. 7.4 is before the bisected change, 7.5 and 24.2 should have it. So bibiset os not clear to me. I'd say issue is different here: you expect proper color in multiselection, whici I do not. If you ungroup fields, they behave as expected.
OK, I was wrong, it is a bug.
Created attachment 191959 [details] Writer document to show the buggy behavior in forms Added a Writer document, because it behaves a little bit different there when reopening a form: Opening a form sets the form to "design mode off". So it will show the fields for input data. Transparency of the multiline textfield will appear here while it is set to same default white background. Switching back to "design mode on" will show all fields without transparency - also the label fields, which were designed transparency on by default. Another bug?
Created attachment 191960 [details] Shows the attached form here while editing and after opening for input data. Form is a Writer form. Switch this bug to a Writer bug to see: This is a allround Writer bug. Base forms are included Writer documents. Bug appears in Version: 24.2.0.1 (X86_64) / LibreOffice Community Build ID: b4d45829793cddfe67b58a53f495528c75738d8a CPU threads: 6; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded
Pending fix: https://gerrit.libreoffice.org/c/core/+/171396
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/001c0934aab5c33b37a75798deb84c20b4b9d365 tdf#155636 tdf#155637 tdf#156962 Consistently use non-native controls It will be available in 25.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.
Fixed in master now, backport for 24-8 pending in Gerrit: https://gerrit.libreoffice.org/c/core/+/171409
Michael Weghorn committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/7f50f18b0fc1e9d52bf2d8f929be8c5e4518ced8 tdf#155636 tdf#155637 tdf#156962 Consistently use non-native controls It will be available in 24.8.1. 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.
Works well now with Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 59cb37a210675d4269c2fcd48feeffe942538891 CPU threads: 6; OS: Linux 6.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded