Bug 100245 - Arrangement (front/back) of picture ignored/messed up on load
Summary: Arrangement (front/back) of picture ignored/messed up on load
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, regression
Depends on:
Blocks:
 
Reported: 2016-06-06 21:24 UTC by kolAflash
Modified: 2017-05-31 05:00 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
example file (127.21 KB, application/vnd.oasis.opendocument.text)
2016-06-06 21:24 UTC, kolAflash
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kolAflash 2016-06-06 21:24:59 UTC
Created attachment 125521 [details]
example file

I tried to annotate a picture with numbers to describe them in the text below the picture. For that I right-clicked the picture and choose "Arrange -> Send to Back". For the moment that worked fine. But after saving, closing and reloading the file, the numbers where behind the picture. This happened again after each reload.


The attached document is taken from a much bigger document where I ran into that problem.

The attached document contains two pictures. First is an SVG graphic (showing the official SVG logo). If I remove it, the bug disappears!?!?

The second picture (the one with the kangaroos) is the one affected by the bug. Try to send it to background to see the numbers behind it, save, close and reload the file and the kangaroo picture will jump back into foreground.


System configuration:
openSUSE 13.2 Linux, 64 bit, german


Tested with the following LibreOffice versions:

5.1.3.2
http://download.opensuse.org/repositories/LibreOffice:/5.1/openSUSE_13.2/

5.1.3.2
https://download.documentfoundation.org/libreoffice/stable/5.1.3/rpm/x86_64/LibreOffice_5.1.3_Linux_x86-64_rpm.tar.gz
https://download.documentfoundation.org/libreoffice/stable/5.1.3/rpm/x86_64/LibreOffice_5.1.3_Linux_x86-64_rpm_langpack_de.tar.gz

5.0.6.3
https://download.documentfoundation.org/libreoffice/stable/5.0.6/rpm/x86_64/LibreOffice_5.0.6_Linux_x86-64_rpm.tar.gz
https://download.documentfoundation.org/libreoffice/stable/5.0.6/rpm/x86_64/LibreOffice_5.0.6_Linux_x86-64_rpm_langpack_de.tar.gz
Comment 1 Buovjaga 2016-06-10 11:54:46 UTC
Yes, it is quite weird that removing the SVG makes the problem go away.
At first I thought this was a dupe of bug 84127, but the SVG thing makes me hesitate.

Arch Linux 64-bit, KDE Plasma 5
Version: 5.3.0.0.alpha0+
Build ID: 2d2a33934ecb952433a635ce5dab76cb2837b8a0
CPU Threads: 8; OS Version: Linux 4.6; UI Render: default; 
Locale: fi-FI (fi_FI.UTF-8)
Built on June 9th 2016
Comment 2 Björn Michaelsen 2016-10-05 13:35:48 UTC
Tested on bibisect-43all source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 (pre 3.5):
1/ kangaroo picture is already in the background on first load.
2/ Putting the kangaroos pict in the foreground and reloading works as expected.
3/ Putting the kangaroos pict to the background and reloading works as expected.

Tested on bibisect-43all source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e (4.3 branchpoint):
1/ kangaroo picture is already in the foreground on first load.
2/ Putting the kangaroos pict in the background and reloading doesnt work as expected.


The behaviour on source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 is consistent, the one on source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e is not (and the same as with current releases).

Thus this is a regression between 3.5 and 4.3:
- setting version to 4.3.0.4, the earliest known broken version
- adding keywords regression, bibisectRequest
Comment 3 Björn Michaelsen 2016-10-05 13:43:08 UTC
Loading the original example file on source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e:
1/ Putting the kangaroo pict in the background and save as foreground-kb.odt
2/ Putting the kangaroo pict in the foreground and save as foreground-kf.odt

and then loading these on source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 shows them as expected. It thus seems that the changes are correctly stored by source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e, but not correctly loaded.
Comment 4 Björn Michaelsen 2016-10-05 22:03:57 UTC
:/ Wonderful. This is an issue that is buried by other issues:
1/ on source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932 this works consistent and as expected.
2/ somewhere in the range between source-hash-4316e643ef345b0f673b4a03a80a4b7cb3185588 and source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc this breaks: From there on the example file only reports a generic "read error".
3/ somewhere between source-hash-d3ff876f3c7f441fd72a037ed31fb973f223ca6d and source-hash-79850f25987d12c8ee91dfd0f699a562f341bf67 the read error is fixed and the example file can be loaded again. However it no longer works consistent and as expected and reproduces the buggy behaviour.

So likely the best would be to fix out what broke/fixed the "read error" first and than look in the range that is shadowed by it when the arrangement broke with e.g. a backported fix. This bug is there at least since 4.2 (the "read error" stuff is there much longer).

Bibisect logs below:
Finding when the example file starts to break with a "read error":

# bad: [752769ad0d2179e17ea0a08cc9004df7b890305b] source-hash-60c64b437c6678dd1d3fa3a6fc2b7da0480890d4
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'last42onmaster' 'oldest'
# skip: [d119104d807d798d21d6ee0fb8644b1ea4266c1e] source-hash-20f2aaced1dabbd62ea516368b85e0e881d42165
git bisect skip d119104d807d798d21d6ee0fb8644b1ea4266c1e
# skip: [50f1f06ed2dd40d2e6f658524a5e160ba1a84807] source-hash-647fb29f528b891a1c92846640f7865f5c1fbe7f
git bisect skip 50f1f06ed2dd40d2e6f658524a5e160ba1a84807
# good: [a71a4447320f177181c9cff9f7c6fd93802cbd8e] source-hash-9afb6e1e38c362a768e8e981f7b03cf8bcaf22cf
git bisect good a71a4447320f177181c9cff9f7c6fd93802cbd8e
# good: [a71a4447320f177181c9cff9f7c6fd93802cbd8e] source-hash-9afb6e1e38c362a768e8e981f7b03cf8bcaf22cf
git bisect good a71a4447320f177181c9cff9f7c6fd93802cbd8e
# bad: [005d70d91c2589e3a200a9dfd4050820cbf73376] source-hash-358b60b3b172968a7605b428af01df456d7669b2
git bisect bad 005d70d91c2589e3a200a9dfd4050820cbf73376
# good: [d3bd29a09db468f81d33acb14551b385b3615472] source-hash-7799ceab2639f1e3bcd35c6cf7e7b064bb1b6e9a
git bisect good d3bd29a09db468f81d33acb14551b385b3615472
# bad: [85835eaea0e00bbe3138486781a507e436bc9263] source-hash-6978ddbf4738b4c53b9d2edbe6d5ad6a061d0d0f
git bisect bad 85835eaea0e00bbe3138486781a507e436bc9263
# bad: [d65a58c31c8da044ef66ae4517fa2fe74cec0019] source-hash-2e053cf5ea4d93a2e1845e795a9c7fe1e08c84af
git bisect bad d65a58c31c8da044ef66ae4517fa2fe74cec0019
# bad: [79e02001f27d33b3b478324ab6fba5683413b4d9] source-hash-b6c016da23d309b4ac7d154bc33a22397974ed73
git bisect bad 79e02001f27d33b3b478324ab6fba5683413b4d9
# bad: [183a576d94de9a9439d580c8b81f335ab57cdbdc] source-hash-a599f5b4b51848e3b397d471c9d12b373caadcef
git bisect bad 183a576d94de9a9439d580c8b81f335ab57cdbdc
# good: [fae90325861bbddd2af90937d29d91637c96661a] source-hash-4316e643ef345b0f673b4a03a80a4b7cb3185588
git bisect good fae90325861bbddd2af90937d29d91637c96661a
# bad: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
git bisect bad ba6eb41acb8df58f3009920f8ab8b32a3e1b764e
# first bad commit: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
# bad: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc
git bisect bad ba6eb41acb8df58f3009920f8ab8b32a3e1b764e
# first bad commit: [ba6eb41acb8df58f3009920f8ab8b32a3e1b764e] source-hash-ae4e4a11d4300f7448cb6bd170fcb034542caddc

Finding when the read error stopped and gave way to the current (buggy) behaviour:
# bad: [752769ad0d2179e17ea0a08cc9004df7b890305b] source-hash-60c64b437c6678dd1d3fa3a6fc2b7da0480890d4
# good: [c2069a369d738078124812312d51f21ea1ce2421] source-hash-f160e4935c474a5293b3d3c11b3d538efb4767a0
git bisect start 'last42onmaster' 'last41onmaster'
# bad: [186181c7d6a957b0fcdbc7ff66866f1abfff988e] source-hash-79850f25987d12c8ee91dfd0f699a562f341bf67
git bisect bad 186181c7d6a957b0fcdbc7ff66866f1abfff988e
# good: [4e504a2344a5356cdcabe4a091f2e626b40aaede] source-hash-f39e8cadc74573a787641615406777da5a9e5343
git bisect good 4e504a2344a5356cdcabe4a091f2e626b40aaede
# good: [92e8808c5d3f3e54366b8bf66bcbd7bb65089c3e] source-hash-d1cbaee70d3f922937a1993914436c8fc899ebfc
git bisect good 92e8808c5d3f3e54366b8bf66bcbd7bb65089c3e
# good: [bac2489ff3b644bd046102e379bff5a6c6c469d9] source-hash-621c1e491e56db5416da1c763aaff862e8ede67a
git bisect good bac2489ff3b644bd046102e379bff5a6c6c469d9
# good: [f47efc54c1f3916052ffda455e5ea179f6aa400a] source-hash-511354504cfc2c8f002752775d5bb336b01bd6ab
git bisect good f47efc54c1f3916052ffda455e5ea179f6aa400a
# good: [f2554751603ad8537257b3cf52d6171056c76eeb] source-hash-f42768fe0b60ecbbe9c68d775329bf28c0690131
git bisect good f2554751603ad8537257b3cf52d6171056c76eeb
# good: [b946f469e1740faa557741120989330fa22df995] source-hash-d3ff876f3c7f441fd72a037ed31fb973f223ca6d
git bisect good b946f469e1740faa557741120989330fa22df995
# first bad commit: [186181c7d6a957b0fcdbc7ff66866f1abfff988e] source-hash-79850f25987d12c8ee91dfd0f699a562f341bf67
Comment 5 kolAflash 2016-11-27 22:37:30 UTC
Still existing in 5.3.0.0 beta1.
Tested on openSUSE 42.2.
Comment 6 Buovjaga 2017-05-28 15:53:30 UTC
This was apparently fixed by the fix for bug 107392

Arch Linux 64-bit, KDE Plasma 5
Version: 5.5.0.0.alpha0+
Build ID: 6dbf9543c6f83d7b1fe7ad27232f65152456619a
CPU threads: 8; OS: Linux 4.10; UI render: default; VCL: kde4; 
Locale: fi-FI (fi_FI.UTF-8); Calc: group
Built on May 27th 2017
Comment 7 vihsa 2017-05-31 05:00:58 UTC
per comment 6, verified, hence status change.