Created attachment 147871 [details] Screenshot of form with red borders arround fields with input required Add the attached screenshot. There you could see a form, which contains some fields with a red border. Input is required for these fields. The fields will switch the colour when input has been made - it's the same behaviour as in XML-Formdocuments. This behaviour only works through macros. Open the second attachment (zipped folder with a database and two files in a folder). For testing the behaviour you have to allow executing of macros. Start the form in the base-file. Switch to new row. If you will do this in all versions up to LO 6.1.3.2 there will be red borders around 4 fields, where input is required. When opening the form in LO 6.1.4.2 and also 6.2.0.1 the borders won't be red. Macro couldn't change the behaviour here. All tested with OpenSUSE 15, 64bit rpm Linux.
Created attachment 147872 [details] Zipped folder with example database and two linked files
Could be this behaviour has something to do while changing "input required" in a form. Its the same version where bug 121188 has been fixed for where this bug appears.
confirm in Version: 6.3.0.0.alpha0+ Build ID: 49fcd3bbb30f93763fc5cb80fa6ac5cec5d00834 CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; TinderBox: Win-x86@42, Branch:master, Time: 2018-12-25_00:15:08 Locale: ru-RU (ru_RU); UI-Language: en-US Calc: threaded
Using Ubuntu 18.04.1 (AMD64) - bibisect in the 6.2 repo (6.1 repo gave no error) Bibisect shows that the anomaly arrived with commit: "Cleanup SvpSalGraphics LineGeometry creation" https://cgit.freedesktop.org/libreoffice/core/commit/?id=32d49d077fff5c63ec731191bff4daed06744afa Adding Author, Armin Le Grand, to CC
Created attachment 147876 [details] screen shot with partial red line drawing Attaching a screen shot of when the software failed to draw the red line around the four controls - as you see here there is a red line on two sides of one of the controls. This is not the case with the LO6.2.0.1 RC release which does not have these two sides in red, only the software out of the bibisect repo had this oddity. Also - in the testing here I tried different VCL settings (GTK2, GTK3, Gen) and it made no difference.
This is only happening in GTK3
Top and left borders are displayed in master after https://cgit.freedesktop.org/libreoffice/core/commit/?id=e18dbb2b7f48a1380e9d1cb6443705d1ce2b2ad5 for bug 126227. @Caolán, I thought you might be interested in this issue... Steps to reproduce: 1. Open attachment 147872 [details] and enable the macro 2. Open the form. 3. Click or hover any form -> In GTK3, the top and left borders are displayed, but not the bottom and right ones
*** Bug 122661 has been marked as a duplicate of this bug. ***
it's also reproducible if macros are disabled, only the top and left borders are displayed in blue
Just for the record, https://cgit.freedesktop.org/libreoffice/core/commit/?id=e18dbb2b7f48a1380e9d1cb6443705d1ce2b2ad5 fixed the same problem in Writer. See https://bugs.documentfoundation.org/attachment.cgi?id=143785, so the current problem is only reproducible in base
It looks like we can safely enough bodge back in extending the damage extents by 1 and then I get the missing border. I have a riskier larger patch which I can try on master afterwards, but not sure enough of it to backport. So I'll try the trivial workaround first.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/eec93ec31fc9bb9daeb4574dccdd3f1bd35b60d3%5E%21 Resolves: tdf#122358 ensure right/bottom borders are included in damage region It will be available in 6.4.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/b8c87fa294678180191588134b9e9c7993a659fc%5E%21 Related: tdf#122358 consistent transformation of damage It will be available in 6.4.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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/d618641195b9e0cf3f6fa1b4e6c1ffa1616b814e%5E%21 Resolves: tdf#122358 ensure right/bottom borders are included in damage region It will be available in 6.2.7. 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.
Caolán McNamara committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/d659308e68431eca64d0d7482c7d7a02f2dec372%5E%21 Resolves: tdf#122358 ensure right/bottom borders are included in damage region It will be available in 6.3.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.
fixed in master, 6-3 and 6-2
Verified in Version: 6.4.0.0.alpha0+ Build ID: 2812610f4f39ed5892da08864893c758325d1d39 CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US Calc: threaded @Caolán, thanks for fixing this issue!!