Description: In a Base form, if you set a field half out of the window and you select it, all the labels of the form disappear. I join a PDF file with screenshot to visualize the bug and a test base file to reproduce it. The workaround is to resize the window. Thanks. Steps to Reproduce: Follow the PDF guide Actual Results: Labels disappear Expected Results: Labels should be visible Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Created attachment 141774 [details] PDF to reproduce the bug
Created attachment 141775 [details] Sample Base file
Confirming with Version: 6.1.0.0.alpha0+ Build ID: b9955b2083ffdc1f99bc8be6b09d806fa3279a16 CPU threads: 8; OS: Mac OS X 10.13.4; UI render: default; Locale: fr-FR (fr_FR.UTF-8); Calc: group
Also occurs in Version: 5.4.6.2 Build ID: 4014ce260a04f1026ba855d3b8d91541c224eab8 Threads CPU : 8; OS : Mac OS X 10.13.4; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group
Also occurs in Version: 5.1.6.2 Build ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909 Threads CPU : 8; Version de l'OS :Mac OS X 10.13.4; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group
Does not occur in Version: 4.1.6.2 Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
Bug first seems to occur in LO 5.1.6.2 Testing with LO4.x release versions up to 4452 showed no problem.
it needs to be bisected with the repos for 5.1
Created attachment 141963 [details] tail of bibisect output Working on debian-buster in the till51 bibisect repository, I see that the bug came into LO somewhere in the 151 or so source commits: commit date s-h -------- ---------- -------- good 0ca724ef 2015-09-01 0c1d3f0c bad 29a332f0 2015-09-02 84eafb6a I am setting keyword bibisected.
I bibisected with bibisect-win32-5.1 and it gave this, which is somewhat puzzling to me: https://cgit.freedesktop.org/libreoffice/core/commit/?id=af11abf3626e12d2b4b7dd9d255c6c71bf84cd4b commit af11abf3626e12d2b4b7dd9d255c6c71bf84cd4b (patch) tree a4ceb7884707e14addb6d10b1989b6c6e96872f6 parent 3fac8cf4f90ce9dca9c7c098a651ee42fe931d2f (diff) SwViewShell::ImplEndAction: still paint directly when non-double-buffering It turns out that in this case it hurts performance if we go via invaliation-then-paint instead of direct painting when double-buffering is not enabled. Related commits: - beb4aa21d61f0d66392d596be86fb57b4b167239 (SwViewShell::ImplEndAction: avoid direct paint, 2015-06-29) and c9175a1bd3249ad573ae6827bf19963a3ebe2fbc (SwViewShell::ImplEndAction: avoid direct PaintDesktop(), 2015-07-03) globally avoided direct paints - 222f10e773ba51a19880be1b798990260c198147 (tdf#93096 sw: fix selection with keyboard outside current view, 2015-08-18) restored direct paint when non-double-buffering for the second commit, this one does the same for the first Change-Id: Ida0c6917a8cdec74209bd64813c7876d4fa61b8a I did checkout the commit and step to previous to verify that the bad/good result is correct. Adding Cc: to Miklos Vajna
So, for a long time we did direct paint, then on 2015-06-29 I changed to lazy paint, then this turned out to be a bad idea, so I went back to the original state with the above commit on 2015-09-01. Could you please confirm that if you test the state right before beb4aa21d61f0d66392d596be86fb57b4b167239, then the problem is still there? Thanks.
(In reply to Miklos Vajna from comment #11) > So, for a long time we did direct paint, then on 2015-06-29 I changed to > lazy paint, then this turned out to be a bad idea, so I went back to the > original state with the above commit on 2015-09-01. Could you please confirm > that if you test the state right before > beb4aa21d61f0d66392d596be86fb57b4b167239, then the problem is still there? > > Thanks. I did git log beb4aa21d61f0d66392d596be86fb57b4b167239 and copied the previous hash. In bibisect-win32-5.1 I did git log --all --grep='39b04ad7cb2e10f32e92d3c9bec57e35f64a3304' to find the hash in the repo and checked it out. I also checked out the commit matching beb4aa21d61f0d66392d596be86fb57b4b167239. The problem is NOT in either commit.
Thanks, some investigation will be needed here, then. Currently I don't understand how it's possible that a revert causes a regression, but the state before the original commit is fine.
What might help is to bisect the beb4aa21d61f0d66392d596be86fb57b4b167239 -> af11abf3626e12d2b4b7dd9d255c6c71bf84cd4b range with beb4aa21d61f0d66392d596be86fb57b4b167239 reverted, probably some breakage was introduced in that range, but it only became visible with the revert. I've started doing that.
So this is a regression from bug 92577.
Created attachment 152006 [details] Minimal reproducer document. A smaller reproducer: a plain Writer document with just one text field and label. Make the window small enough that only part of the text field shows up, then click into the text field -> label disappears.
Miklos Vajna committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/00dfa6dc890dbbc8140fe613599becb5e4c55486%5E%21 tdf#117347 sw form controls: fix disappearing FixedText when editing TextField 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.
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-3": https://git.libreoffice.org/core/+/802e3a960e166b24e18da04a821862620047f37f%5E%21 tdf#117347 sw form controls: fix disappearing FixedText when editing TextField It will be available in 6.3.0.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.
Verified in Version: 6.4.0.0.alpha0+ Build ID: ec905d131374f0860bac77c52873eed984b1966f 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 @Miklos, thanks for fixing this issue!!
Miklos Vajna committed a patch related to this issue. It has been pushed to "libreoffice-6-2": https://git.libreoffice.org/core/+/54b588724005c502590a2f43ea42f6b2fb8fb1f2%5E%21 tdf#117347 sw form controls: fix disappearing FixedText when editing TextField It will be available in 6.2.5. 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.
*** Bug 107305 has been marked as a duplicate of this bug. ***