Bug 117347 - All labels disappear in Base Form if a selected field is not within visual display area
Summary: All labels disappear in Base Form if a selected field is not within visual di...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Base (show other bugs)
Version:
(earliest affected)
5.1.6.2 release
Hardware: All All
: high major
Assignee: Miklos Vajna
URL:
Whiteboard: target:6.4.0 target:6.3.0.1 target:6.2.5
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Database-Forms
  Show dependency treegraph
 
Reported: 2018-04-30 12:58 UTC by Jean-Sebastien Bevilacqua
Modified: 2019-06-10 15:43 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
PDF to reproduce the bug (98.81 KB, application/pdf)
2018-04-30 13:01 UTC, Jean-Sebastien Bevilacqua
Details
Sample Base file (94.53 KB, application/vnd.oasis.opendocument.database)
2018-04-30 13:01 UTC, Jean-Sebastien Bevilacqua
Details
tail of bibisect output (2.44 KB, text/plain)
2018-05-08 03:17 UTC, Terrence Enger
Details
Minimal reproducer document. (8.73 KB, application/vnd.oasis.opendocument.text)
2019-06-07 09:14 UTC, Miklos Vajna
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Jean-Sebastien Bevilacqua 2018-04-30 12:58:52 UTC
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
Comment 1 Jean-Sebastien Bevilacqua 2018-04-30 13:01:04 UTC
Created attachment 141774 [details]
PDF to reproduce the bug
Comment 2 Jean-Sebastien Bevilacqua 2018-04-30 13:01:33 UTC
Created attachment 141775 [details]
Sample Base file
Comment 3 Alex Thurgood 2018-05-02 07:07:52 UTC
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
Comment 4 Alex Thurgood 2018-05-02 07:11:03 UTC
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
Comment 5 Alex Thurgood 2018-05-02 07:12:56 UTC
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
Comment 6 Alex Thurgood 2018-05-02 07:14:24 UTC
Does not occur in

Version: 4.1.6.2
Build ID: 40ff705089295be5be0aae9b15123f687c05b0a
Comment 7 Alex Thurgood 2018-05-02 07:18:22 UTC
Bug first seems to occur in LO 5.1.6.2

Testing with LO4.x release versions up to 4452 showed no problem.
Comment 8 Xisco Faulí 2018-05-02 14:52:26 UTC
it needs to be bisected with the repos for 5.1
Comment 9 Terrence Enger 2018-05-08 03:17:52 UTC
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.
Comment 10 Buovjaga 2018-06-06 13:10:48 UTC
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
Comment 11 Miklos Vajna 2018-07-03 08:29:10 UTC
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.
Comment 12 Buovjaga 2018-07-03 16:37:16 UTC
(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.
Comment 13 Miklos Vajna 2018-07-04 07:16:29 UTC
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.
Comment 14 Miklos Vajna 2019-06-06 15:27:35 UTC
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.
Comment 15 Miklos Vajna 2019-06-07 07:53:48 UTC
So this is a regression from bug 92577.
Comment 16 Miklos Vajna 2019-06-07 09:14:35 UTC
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.
Comment 17 Commit Notification 2019-06-07 12:18:20 UTC
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.
Comment 18 Commit Notification 2019-06-07 18:34:12 UTC
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.
Comment 19 Xisco Faulí 2019-06-10 10:18:15 UTC
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!!
Comment 20 Commit Notification 2019-06-10 15:43:49 UTC
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.