Created attachment 96366 [details]
ooxml document with picture which cannot be deleted
Steps to reproduce:
1. Open attachment
2. Pick Arrow tool from Drawing toolbar
3. Select picture with mountains in center of first page, press Del (you'll have to drag a little select area, just clicking won't work; area does not have to cover whole picture, just any part)
4. Save in odt, reload
Deleted Picture re-appear in center of page again (and in object browser (F5).
In odt, picture always reappear on first page, even when deleted from all (even after re-opening odt and deleting from there). When saving to docx, picture reappears on other pages.
Operating System: Windows XP
Version: 18.104.22.168 release
Analysis with LibO 22.214.171.124 on Win7 :
The "mountain" picture belongs to the page (header/footer) part, not to the text body.
First page has the "First Page" page type, with "Same content on first page" deselected, other pages have the "Default Style" page type, also with "Same content on first page" deselected.
Without any change, you delete on page # :
- 1: picture in the first page of page (only one exists) with "First Page" style (page 1),
- 2: picture in the first page of pages with "Default Style" style (page 2),
- 3: picture in the other pages of pages with "Default Style" style (pages 3-end).
It remains the picture in the other page(s) with "First Page" style :
- OK, there are none in the attachment ; there should not exist any, in any doc,
- but LibO doesn't know this subtility, it allows them to exist!
- the bug is that the picture, deleted from the first page background and still existing in the following page backgrounds, is nevertheless drawn in the first page : this is WRONG (bug set to NEW),
- to delete it, check the "Same content on first page" in "First Page" page style before deleting, so that you see all.
Just wow. Thanks for explanation, I tried to analyse what is happening, but didn't get any close.
Confirmed in Linux Mint in 4.2.5 and 4.3.1 and Windows 7 in 4.2.4. It works fine in 4.0.6 and 4.1.6.
Major - loss of data (or I guess in this case...unloss of data? ;) )
Highest - default is high but bumping up because of regression + our native format. Adding to MAB list
da4ad98ef394c644bb0aa80161ff599330862e7c is the first bad commit
Author: Bjoern Michaelsen <email@example.com>
Date: Thu Oct 17 19:23:14 2013 +0000
Author: Stephan Bergmann <firstname.lastname@example.org>
AuthorDate: Wed Jul 24 09:31:41 2013 +0200
Commit: Stephan Bergmann <email@example.com>
CommitDate: Wed Jul 24 09:31:41 2013 +0200
Keep passing XComponentContext into officecfg:: wrapper fns, where available
:100644 100644 d4197fbc8076054b77cfb7c6daccbaef3a07b471 59f4adcea92e0e0973176750fb770506c85f24b7 M autogen.log
:100644 100644 5d355f4aa08496286f3179dabdf19a5a74798d00 88ba6862fe738a0310ba706546ab52ab6d35bb50 M ccache.log
:100644 100644 dd1c28d6eca33820a174c351dd396abd5c7e07e8 191b1e373284bcf823929c6f65e7a824c8ccfb02 M commitmsg
:100644 100644 8bbc92e1cdf5703e61a7d0b7b13f53d3f6969c69 84ff52ee125b1b4f03b34c9b07d5e55947899cdb M dev-install.log
:100644 100644 57ecc496b83888705cbd62221128892c9dde7fde 0d7d592ac09c717e3836f6287f6edf0e05bad6b0 M make.log
:040000 040000 74dd0918665f15297668258400238c4d06c65a40 d165a641190b516218263ac8bc3750d6b32146a6 M opt
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# bad: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect bad 4850941efe43ae800be5c76e1102ab80ac2c085d
# skip: [a043626b542eb8314218d7439534dce2fc325304] source-hash-9379a922c07df3cdb7d567cc88dfaaa39ead3681
git bisect skip a043626b542eb8314218d7439534dce2fc325304
# skip: [aba65c3e4c0df07e4909aeefb758cdb688242bf6] source-hash-827524abfb4b577d08276fde40929a9adfb7ff1a
git bisect skip aba65c3e4c0df07e4909aeefb758cdb688242bf6
# skip: [c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31] source-hash-c69ed33628ec0b7abf6296539cf280d6c4265930
git bisect skip c81a8a0dcfc1ed095a80e4485c89dd0fcaf73f31
# skip: [9771d0c212cfa71b07742ff3dc5c05df22d600eb] source-hash-a9a0933ec67eab0ec31c8fadb60fb8e8e3e90485
git bisect skip 9771d0c212cfa71b07742ff3dc5c05df22d600eb
# bad: [32c7515d0a5143cdc0c174c7d9767e00a0bef0c8] source-hash-4450b1b93f7f7b5f97c631fe767b1156350a9227
git bisect bad 32c7515d0a5143cdc0c174c7d9767e00a0bef0c8
# good: [e128a0b9bd133d989b87354bd271ef25c642b7bc] source-hash-7be71336862204f0763fc2f8cf62a6f48f341114
git bisect good e128a0b9bd133d989b87354bd271ef25c642b7bc
# bad: [a22bedaefd4f837e884f70bc50b0f916160b4c49] source-hash-a4c385f1aa98b5fb2d85136b653365fb6baa33f8
git bisect bad a22bedaefd4f837e884f70bc50b0f916160b4c49
# bad: [b39f384b5baf459aa0bd37c20d5886b040293086] source-hash-f0833d965d20594c0f2d74ffca95589a572e012c
git bisect bad b39f384b5baf459aa0bd37c20d5886b040293086
# good: [b5e6283a204221f3f9f830c2b3b75c195f8a51bc] source-hash-f4546b72702dbe30505594a8307dd402e81a0303
git bisect good b5e6283a204221f3f9f830c2b3b75c195f8a51bc
# bad: [2d9baecf3ce2ea1ec8bea3e842eed595061eeef6] source-hash-ff51a2b64571a8d72ff4d8a8181d17cf98c42e69
git bisect bad 2d9baecf3ce2ea1ec8bea3e842eed595061eeef6
# bad: [da4ad98ef394c644bb0aa80161ff599330862e7c] source-hash-570fe620e9d573cfc9fc260e6518563c6a6c1a3c
git bisect bad da4ad98ef394c644bb0aa80161ff599330862e7c
# first bad commit: [da4ad98ef394c644bb0aa80161ff599330862e7c] source-hash-570fe620e9d573cfc9fc260e6518563c6a6c1a3c
(This is an automated message.)
Setting priority to highest as this is a MAB. This is part of an effort to make the importance of MAB reflected in priority too.
(In reply to Joel Madero from comment #4)
So bibisected range is f4546b72702dbe30505594a8307dd402e81a0303..570fe620e9d573cfc9fc260e6518563c6a6c1a3c with only 6 commits in sw/, none of which seem to be obviously guilty.
still reproducible under 126.96.36.199.alpha0+
Build ID: f20043a0805c3a75eb4024ed59f45291aea93ac0
TinderBox: Win-x86@39, Branch:master, Time: 2014-12-03_01:16:50
moving this to mab4.3 list since 4.2.x is end of life
The behaviour seems to have changed as of the below commit.
Adding Cc: to firstname.lastname@example.org; Any chance you could take a look at this? Thanks
Author: Adam Co <email@example.com>
Date: Sun Jul 21 16:27:45 2013 +0300
fdo#66145: fix for FirstIsShared flag
Reviewed-by: Fridrich Strba <firstname.lastname@example.org>
Tested-by: Fridrich Strba <email@example.com>
I cannot reproduce this with fresh builds from libreoffice-4-4 and master branches.
Andras is right: this bug is gone in 188.8.131.52 as well
this is another self-resolving MAB
Migrating Whiteboard tags to Keywords: (Bibisected)