Bug 120839 - Textbox content disappearing (white box) when moving to a certain position
Summary: Textbox content disappearing (white box) when moving to a certain position
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: All All
: medium normal
Assignee: Patrick Jaap
URL:
Whiteboard: target:6.3.0
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Textbox
  Show dependency treegraph
 
Reported: 2018-10-23 14:55 UTC by Telesto
Modified: 2019-02-11 14:31 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Example file (23.31 KB, application/vnd.oasis.opendocument.text)
2018-10-23 14:55 UTC, Telesto
Details
Screencast (434.79 KB, video/mp4)
2018-10-23 14:56 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-10-23 14:55:22 UTC
Description:
Textbox content disappearing (white box) when moving to a certain position

Steps to Reproduce:
1. Open the attached file
2. Scroll to the last page
3. Move the textbox "Hello World' at the top of the page (screencast)

Actual Results:
Empty white box

Expected Results:
Text/background should be visible


Reproducible: Always


User Profile Reset: No



Additional Info:
Version: 6.2.0.0.alpha0+
Build ID: 3846561f79cf9065abd9ca83c9fbfbe7e52e28e2
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-10-20_23:33:00
Locale: nl-NL (nl_NL); Calc: CL
Comment 1 Telesto 2018-10-23 14:55:41 UTC
Created attachment 145937 [details]
Example file
Comment 2 Telesto 2018-10-23 14:56:21 UTC
Created attachment 145938 [details]
Screencast
Comment 3 Dieter 2018-10-23 15:35:15 UTC
I confirm this with

Version: 6.2.0.0.alpha1+ (x64)
Build ID: 8274c4c62df5b937b3f0bec9e1eeca85f3b219d4
CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2018-10-22_01:47:50
Locale: en-US (de_DE); Calc: CL

and

Version: 6.0.6.2 (x64)
Build-ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77
CPU-Threads: 4; BS: Windows 10.0; UI-Render: Standard; 
Gebietsschema: de-DE (de_DE); Calc: group
Comment 4 Telesto 2018-10-23 17:40:37 UTC
Found in
Version: 5.4.1.0.0+
Build ID: f200d5700782ae179fd96b6ad4b0fe8e7edd1616
CPU threads: 4; OS: Windows 6.29; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL

but not in 
5.3.0

Attempted a bibisect on Windows; but got only a long list of possible commits (+/- 200) starting with 3e973760b788c49396c7a18404bffa0505e65a04
Comment 5 raal 2018-10-29 12:43:42 UTC
   bisected with 6.1 repo: 
in this commit error occurs, one commit before the error doesn't occurs - when I move image up, then it jumps on page before and image is still present. But I'm not sure if bibisect is correct, Patrick please can you look if your commit is relevant?   
	 source fe3d5766fa3c42f6cf8d1ea47af820e0b1c1cf48
author	Patrick Jaap <patrick.jaap@tu-dresden.de>	2018-04-10 15:29:56 +0200
committer	Miklos Vajna <vmiklos@collabora.co.uk>	2018-04-18 09:43:09 +0200
commit fe3d5766fa3c42f6cf8d1ea47af820e0b1c1cf48 (patch)
tree 4b83e47d5a7477a12d2aee48ac4894ca7a61a991
parent 00ff4d198313265ba736a6e234b4278166d1c3e4 (diff)
tdf#116195 swap a compatibility value
Comment 6 Patrick Jaap 2018-10-29 15:42:03 UTC
Hi!
Thanks for the report. The bug may be related to my patch. I'll take a look into it.
Comment 7 Patrick Jaap 2018-10-29 17:17:25 UTC
Hi! First of all, I can reproduce the bug. Then, I reverted the patch fe3d5766fa3c42f6cf8d1ea47af820e0b1c1cf48 and, indeed, it affects the bug. Without my patch there is still another bug: you can't place the image at the top of the page. It always jumps to the previous page. I will look at this bug again later this week. Maybe your document triggers some corner case which can be treated in some way.
Comment 8 Patrick Jaap 2018-11-07 07:50:22 UTC
patch is on the way

https://gerrit.libreoffice.org/#/c/62987/
Comment 9 Commit Notification 2018-12-14 15:09:26 UTC
Patrick Jaap committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/+/98e84dc591e23bd8e43c7c6d5ec6511eafa91900%5E%21

tdf#120839: Special handling for anchored-to-char frames

It will be available in 6.3.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 10 Xisco Faulí 2019-01-14 09:52:12 UTC
A polite ping to Patrick Jaap:
Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing?
Thanks
Comment 11 Patrick Jaap 2019-01-14 09:57:01 UTC
Bug is fixed in 6.3
Comment 12 Xisco Faulí 2019-01-15 12:46:28 UTC
(In reply to Patrick Jaap from comment #7)
> Hi! First of all, I can reproduce the bug. Then, I reverted the patch
> fe3d5766fa3c42f6cf8d1ea47af820e0b1c1cf48 and, indeed, it affects the bug.
> Without my patch there is still another bug: you can't place the image at
> the top of the page. It always jumps to the previous page. I will look at
> this bug again later this week. Maybe your document triggers some corner
> case which can be treated in some way.

Hi Patrick Jaap,
I see the original problem is fixed in

Version: 6.3.0.0.alpha0+
Build ID: cec7ae9f3c69ecc83462f28fc4987e37dc1b420e
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

however, I still see the behaviour you described in comment 7.
Should I create a follow-up bug ?
Comment 13 Patrick Jaap 2019-01-15 12:56:47 UTC
Hi Xisco!

I don't know. You can place the image with your arrow keys. For me it is not a problem any more.
Comment 14 Xisco Faulí 2019-01-15 13:02:35 UTC
(In reply to Patrick Jaap from comment #13)
> Hi Xisco!
> 
> I don't know. You can place the image with your arrow keys. For me it is not
> a problem any more.

Yep, you're right, but not with the mouse. I'll report a follow-up bug