Created attachment 157165 [details] Screenshot "Field properties lost" (except Format example) Following bug appears with Version: 6.4.0.2 Build ID: 08d19fecdc7a2298d051e19cfdb7c35544855fc3 CPU threads: 6; OS: Linux 4.12; UI render: default; VCL: kf5; Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: threaded Open a database, for example an internal Firebird. Open a table and try to edit a field with Field Type VARCHAR. Field properties at the bottom of the editor will show only "Format example" (see attached screenshot). Resize the window a little bit. The other properties will also appear. Detected with OpenSUSE 15.1 64bit rpm Linux. It's a regression, because it doesn't appear in LO 6.3.4.2
I can't reproduce it in Version: 6.5.0.0.alpha0+ Build ID: fc1f85127968d1c2e0a53dace51bf8a78f9e6ca5 CPU threads: 4; OS: Linux 4.19; UI render: default; VCL: x11; Locale: en-US (en_US.UTF-8); UI-Language: en-US Calc: threaded - Does it happen if you launch LibreOffice with SAL_USE_VCLPLUGIN=gen instdir/program/swriter ? - Does it happen with any base file?
(In reply to Xisco Faulí from comment #1) > > - Does it happen if you launch LibreOffice with SAL_USE_VCLPLUGIN=gen > instdir/program/swriter ? > - Does it happen with any base file? Have tested with Version: 6.5.0.0.alpha0+ Build ID: d1730033b4fa1f0cfeedd136dfb23ec01a194ec0 CPU threads: 6; OS: Linux 4.12; UI render: default; VCL: x11; TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-01-20_03:30:24 Locale: de-DE (de_DE.UTF-8); UI-Language: en-US Calc: threaded by the command you described. Bug appears the same way in any database and any table. I have only to open the table for editing and move by mouse to a field, which is VARCHAR. Bug also appears with the same command and LO 6.4.0.2 There has been changed something in the width of the fields, which should be shown in the fieldproperties of the tableeditor. The fields will be shown after resizing the editor all in the same width as the field for "Format Example" together with the button with tree points on the right side. All the other fields have been smaller in LO 6.3 and older versions.
I can reproduce, just that for me, "Default value" and "Format example" are initially shown, and "Entry required" and "Length" are missing until resizing the window. Version: 6.5.0.0.alpha0+ Build ID: fc1f85127968d1c2e0a53dace51bf8a78f9e6ca5 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: x11; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded and Version: 6.5.0.0.alpha0+ Build ID: fc1f85127968d1c2e0a53dace51bf8a78f9e6ca5 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded Interestingly, using SAL_USE_VCLPLUGIN=gtk3, all of the properties are totally missing with the same LO version, but that seems to be a different issue, since I can also reproduce the issue described here using the gtk3 VCL plugin with an older LO version: Version: 6.4.0.0.beta1+ Build ID: 39e138902d05fbb00fda8003908c851d2f3ecb00 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: en-GB (en_GB.UTF-8); UI-Language: en-US Calc: threaded
(In reply to Michael Weghorn from comment #3) > ... > Interestingly, using SAL_USE_VCLPLUGIN=gtk3, all of the properties are > totally missing with the same LO version, but that seems to be a different > issue, since I can also reproduce the issue described here using the gtk3 > VCL plugin with an older LO version: > > Version: 6.4.0.0.beta1+ > Build ID: 39e138902d05fbb00fda8003908c851d2f3ecb00 > CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; > Locale: en-GB (en_GB.UTF-8); UI-Language: en-US > Calc: threaded > ... It corresponds to tdf#130516 I wonder if both bugtrackers could be a regression from https://cgit.freedesktop.org/libreoffice/core/commit/?id=8c66efa030e98cfdf5da20be368566d64e43c5d1
(In reply to Julien Nabet from comment #4) > It corresponds to tdf#130516 > > I wonder if both bugtrackers could be a regression from > https://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=8c66efa030e98cfdf5da20be368566d64e43c5d1 I didn't check yet, but it should be possible to verify or refute this assumption by testing this and the previous commit in the corresponding bibisect repository.
Hi, I do believe this is a duplicate of bug 130623. *** This bug has been marked as a duplicate of bug 130623 ***