Bug 104020 - FILEOPEN: Saving business cards loses positioning of image
Summary: FILEOPEN: Saving business cards loses positioning of image
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
5.1.4.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
Depends on:
Blocks: Labels-BusinessCards
  Show dependency treegraph
 
Reported: 2016-11-18 22:05 UTC by Thomas Hehl
Modified: 2019-10-19 02:42 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Business card document (85.16 KB, application/vnd.oasis.opendocument.text)
2016-11-21 12:36 UTC, Thomas Hehl
Details
Layout with LibO 4.4.6.3 (56.86 KB, image/png)
2016-12-01 15:05 UTC, Telesto
Details
Layout with LibO 5.4.0.0 (60.02 KB, image/png)
2016-12-01 15:06 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Hehl 2016-11-18 22:05:09 UTC
I have attached the problematic file. When you open it, (it doesn't matter whether you update the links) you will see that the images are aligned with the top margin. Move the image.

Right click on the top left image and click format image. Change position to horizontal, center, to paragraph text area and vertical, center, to paragraph text area and hit OK. Click Synchronize Labels.

Everything appears correctly. This is how it should look. Save it and close writer.

Re-open the document. Images are again jacked up.
Comment 1 Xisco Faulí 2016-11-19 00:31:13 UTC
Hello Thomas,

Thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. 
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided.
(Please note that the attachment will be public, remove any sensitive information before attaching it. 
See https://wiki.documentfoundation.org/QA/FAQ#How_can_I_eliminate_confidential_data_from_a_sample_document.3F for help on how to do so.)
Comment 2 Thomas Hehl 2016-11-21 12:36:45 UTC
Created attachment 128922 [details]
Business card document
Comment 3 Telesto 2016-12-01 15:03:34 UTC
Confirming that the images are aligned with the top margin when opening, with:
Version: 5.4.0.0.alpha0+
Build ID: 4130c8def811d1dcc87eacaa8ae48ba02738a790
CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2016-11-29_01:03:18
Locale: nl-NL (nl_NL); Calc: CL

but not with:
Versie: 4.4.6.3 
Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
Locale: nl_NL
Comment 4 Telesto 2016-12-01 15:05:59 UTC
Created attachment 129186 [details]
Layout with LibO 4.4.6.3
Comment 5 Telesto 2016-12-01 15:06:42 UTC
Created attachment 129187 [details]
Layout with LibO 5.4.0.0
Comment 6 Xisco Faulí 2016-12-01 15:25:38 UTC
(In reply to Telesto from comment #3)
> Confirming that the images are aligned with the top margin when opening,
> with:
> Version: 5.4.0.0.alpha0+
> Build ID: 4130c8def811d1dcc87eacaa8ae48ba02738a790
> CPU Threads: 4; OS Version: Windows 6.19; UI Render: default; 
> TinderBox: Win-x86@42, Branch:master, Time: 2016-11-29_01:03:18
> Locale: nl-NL (nl_NL); Calc: CL
> 
> but not with:
> Versie: 4.4.6.3 
> Build ID: e8938fd3328e95dcf59dd64e7facd2c7d67c704d
> Locale: nl_NL

Hi Telesto, is it the same issue at opening time than a saving time described in the description?
Comment 7 QA Administrators 2017-12-02 16:26:11 UTC Comment hidden (obsolete)
Comment 8 Thomas Hehl 2017-12-02 20:00:34 UTC
Recreated issue in current version: Version: 5.4.2.2
Build ID: 22b09f6418e8c2d508a9eaf86b2399209b0990f4
CPU threads: 4; OS: Windows 6.2; UI render: default; 
Locale: en-US (en_US); Calc: group
Comment 9 Buovjaga 2018-05-30 18:21:15 UTC
Bisect first gave me the wrong blamed commit (it was actually a good commit), but I advanced forwards one commit at a time (maybe under 10 times).

The first bad commit is this: https://cgit.freedesktop.org/libreoffice/core/commit/?id=e807dafa5ba9247479f925f96474d88d58450be9

commit	e807dafa5ba9247479f925f96474d88d58450be9 (patch)
tree	7c35799a8c6b1c7dc7791da0621c6299bcd9f709
parent	c62ab814d8df19e16c82262093a350fac93d328d (diff)
loplugin:stringconstant: OUStringBuffer: appendAscii -> append
Change-Id: I5aa87d22f0b810597ba5dd2f8b98d148ddb99020

Adding Stephan to CC

I used this solution to advance forwards in the history: https://stackoverflow.com/a/33668818
Comment 10 Stephan Bergmann 2018-05-31 07:21:18 UTC
* I don't understand how to execute the reproducer recipe from comment 0 with a current LO master (e.g., in the right-click context menu of the top left image, there's no "format image" item).

* If you bisected (i.e., rebuilt LO from each bisected code revision), did you try a build with e807dafa5ba9247479f925f96474d88d58450be9 reverted?  For one, the change itself looks correct; and for another, the changed code (GridPrinter) appears to only be used as a debugging aid across the code base, so unlikely that is involved here.

* If instead you bibisected, what repo did you use?
Comment 11 Buovjaga 2018-05-31 08:24:40 UTC
(In reply to Stephan Bergmann from comment #10)
> * I don't understand how to execute the reproducer recipe from comment 0
> with a current LO master (e.g., in the right-click context menu of the top
> left image, there's no "format image" item).
> 
> * If you bisected (i.e., rebuilt LO from each bisected code revision), did
> you try a build with e807dafa5ba9247479f925f96474d88d58450be9 reverted?  For
> one, the change itself looks correct; and for another, the changed code
> (GridPrinter) appears to only be used as a debugging aid across the code
> base, so unlikely that is involved here.
> 
> * If instead you bibisected, what repo did you use?

You only have to open the file and see, if the images are jutting out of their label frames like in attachment 129187 [details] (bad result).

I did not rebuild, but the repo I used contains all the commits: bibisect-win32-5.1 from https://wiki.documentfoundation.org/QA/Bibisect/Windows#Versions
Comment 12 Stephan Bergmann 2018-06-01 09:18:38 UTC
Hm, with the bibisect-win32-5.1 I can indeed reproduce that

> commit 98cd24c7e539d7ce0b1f2ae069926815e149d2b8
> Author: Norbert Thiebaud <nthiebaud@gmail.com>
> Date:   Mon Aug 31 07:30:22 2015 -0700
> 
>     source sha:e807dafa5ba9247479f925f96474d88d58450be9
> 
>     source sha:e807dafa5ba9247479f925f96474d88d58450be9

displays businesscard.odt wrongly, while its predecessor

> commit aef4f3dd8ca1c18078866e42a886c23f69704657
> Author: Norbert Thiebaud <nthiebaud@gmail.com>
> Date:   Mon Aug 31 05:18:00 2015 -0700
> 
>     source sha:c62ab814d8df19e16c82262093a350fac93d328d
> 
>     source sha:c62ab814d8df19e16c82262093a350fac93d328d

displays it correctly.  (And c62ab814d8df19e16c82262093a350fac93d328d is indeed the predecessor of e807dafa5ba9247479f925f96474d88d58450be9 in the core repo; i.e., there's no commits in the bibisect repo that cover multiple core commits.)  However, when I revert e807dafa5ba9247479f925f96474d88d58450be9 on recent LO master (also on Windows), businesscard.odt still displays wrongly (which matches the impression that that commit looks good and rather unrelated to the broken functionality).  Something must be fishy with that bibisect repo.
Comment 13 Buovjaga 2018-06-01 13:13:06 UTC
This is difficult to bisect. Now I tried it with a fresh profile per launch:
rm -rf instdir/user && instdir/program/soffice

I was pointed to some typo-fixing commit! I walked between the commits a bit and seemed to be getting totally random results.
Comment 14 Xisco Faulí 2018-06-01 15:54:27 UTC
This is weird, on mac the regression was introduced much later, in range https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=9e9f310648992e103d664a82a96ed5bdee1db4ad..5244a49b92fa5acfa7445292775edf61bde6b232 (bibisected with bibisect-mac64-6.0-32commits while on linux it points to range  https://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=ba70050dc37f82306a8a3c5815372a4b9fff18fc..3ecef8cedb215e49237a11607197edc91639bfcd ( bibisected with lo-linux-dbgutil-daily-till51 )
Comment 15 Xisco Faulí 2018-06-01 16:15:54 UTC
Reverting https://cgit.freedesktop.org/libreoffice/core/commit/?id=6ade80cf142664e78954c7544534e9436ceb90c7 fixes the problem on Mac but not on Linux...

Adding Miklos to the loop... he might have some insight here as well...
Comment 16 Miklos Vajna 2018-06-04 06:57:41 UTC
(In reply to Xisco Faulí from comment #15)
> Adding Miklos to the loop... he might have some insight here as well...

Hm, no idea off the top of my head. I don't see any really problematic commits in the Linux bibisect range, so I guess the easiest would be to bisect this.
Comment 17 QA Administrators 2019-10-19 02:42:20 UTC
Dear Thomas Hehl,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug