Created attachment 189193 [details] multiline textfield before refreshing When using a multline textfield for entering remarks ("Bemerkung" in the screenshot) in LO writer, which is an interface for entering data into a database in this case, the GUI is defunct after scrolling. There are overlays of the multiline textfield which makes the interface unusable. Two screenshots are attached, one before scrolling and one after scrolling. The reason seems to be that the area of the multiline textfield is not graphically refreshed while opening the document or e.g. scrolling the document. When we change the multiline textfield to "multiline textfield with formatting" via the textfield's properties dialog in LOWriter, the properties dialog's data tab disappears and the connection to the correspondent data base field breaks. When switching back to a multiline or an oneline textfield, the data tab appears again but it is blank. this can be repoduced with two newer versions of Libreoffice: Version: 7.5.4.1 (X86_64) / LibreOffice Community Build ID: 50(Build:1) CPU threads: 12; OS: Linux 5.14; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 4:7.5.5~rc2-0ubuntu0.20.04.1~lo2 Calc: threaded
Created attachment 189194 [details] multiline textfield after scrolling
Thank you for the report. Can you please attach an example document so we are sure we are using the same elements when testing? Thank you!
Created attachment 189512 [details] example Document for bug with multline text field
Created attachment 189513 [details] Screenshot while typing in the test document Screenshot taken with Version: 7.5.6.2 (X86_64) / LibreOffice Community Build ID: 50(Build:2) CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (de_DE.UTF-8); UI: de-DE Ubuntu package version: 4:7.5.6~rc2-0ubuntu0.20.04.1~lo1 Calc: threaded
Created attachment 189514 [details] screenshot of test document after scrolling
Thank you! Reproduced in: Version: 7.5.6.2 (X86_64) / LibreOffice Community Build ID: f654817fb68d6d4600d7d2f6b647e47729f55f15 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded and 7.6.1.1. Also with qt5 (cairo+xcb). - Scrolling leaves horizontal lines on the frame. - When adding lines after reaching the bottom of the object, the characters keep overlapping and accumulating. Not reproduced with gtk3 VCL plugin. Not reproduced in 7.4.7.2 -> regression. Bibisected with linux-64-7-5 repo to first bad commit f8a0d8ee676d110bfe19fbb3396292db93e6d69c which points to core commit 0e14dbc9ecdf6abae3ae3089e3b4e22f27dd4cb1 which is a cherrypick of: commit 0e14dbc9ecdf6abae3ae3089e3b4e22f27dd4cb1 author Caolán McNamara Thu May 04 10:24:53 2023 +0100 committer Michael Stahl Fri May 05 10:48:33 2023 +0200 Resolves: tdf#155029 set StandardStyles before updateFromModel Reviewed-on: https://gerrit.libreoffice.org/c/core/+/151370 Caolán, can you please have a look? Likely the same issue as bug 155637.
*** Bug 157471 has been marked as a duplicate of this bug. ***
*** Bug 158271 has been marked as a duplicate of this bug. ***
Created attachment 191890 [details] base test the problem occurs on version 7.6.4.1
The bug still exists in 7.6.6.3.
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.
Hi, I'm new here and don't know, whether my need for clarification is right here cause it refers to LO writer. Struggling for days with LO 24.2.5.2 base on kubuntu 24.04 with "dark" mode. And as all looks fine with LO 7.6.7.2 on M$ Win 11 in standard mode, I've found, that only multiline text had "wrong colors" (black on darkgrey instead of black on white) on a linux machine. To be sure not using fixed colors I've switched all background and text colors to "standard" by Basic script. No change, but then I saw also the not refreshing multiline text (switching from dataset to dataset in my case). Simple text looks fine so far. The described behaviour of missing refresh in this thread for LO writer would also explain what I see here in LO base forms. So does the fix affect also LO base ?
> So does the fix affect also LO base ? Yes, it also applies for multiline fields in Base forms.
The bug in write-form-fields is resolved in Version: 24.8.1.2 (X86_64) / LibreOffice Community Build ID: 87fa9aec1a63e70835390b81c40bb8993f1d4ff6 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_IE.UTF-8); UI: de-DE Calc: threaded Thanks for your help!