Hi vermontpoet,

Thanks for reporting and your test document.
Trying in 4.4.3.2, indeed I can't send an image to the background with the context menu. Definitely a bug.

But I can do it with the tab Wrap from the Image dialog (double click on the image).
Can you pls check that?


QA to do: 
 - duplicates ?
 - bug first occurs in / bibisect..

Created attachment 116567 [details]
Attempt to background image via "Wrap" tab.

(In reply to Cor Nouws from comment #1)

> But I can do it with the tab Wrap from the Image dialog (double click on the
> image).
> Can you pls check that?

Okay, just sent another attachment. Attempting to background the image via the [Wrap] tab, Settings ---> Through, and "In Background" checked, causes the image to disappear.

hi,

Thanks for the example
The problem is related to the frame..
If you set the background to white and transparency to 100%, that problem is solved. See bug 34585

Let's keep this issue for the context menu problem.
Works in 366 any way, so bibisectrequest is justified.

Cheers,
Cor

Can I get a little clarification as to what I'm looking for? I've right clicked on some of the images - some allow me to send to back, others do not (haven't investigated why).

But I haven't found anything that is a regression to bibisect. Can someone direct me exactly to what I'm looking for and then I'll bibisect if appropriate.

Thanks

(In reply to Joel Madero from comment #6)
> Can I get a little clarification as to what I'm looking for?

Comment #4 and the summary should do that?

This is weird, I tried bibisecting this bug (reproduction: right click on an image in attached sample, then Wrap -> In Background; image is sent to background normally when it works, disappears when it doesn't), and even the oldest commit, the 4.3 branch point from May 21, 2014 [1] exhibits the bug. However, in 4.3.0.4 release (from July 25) [2] it's fine. How is that possible? It couldn't possibly have been there at branch point, then fixed in 4.3 only before first release, could it?

I went through the normal bisecting procedure, progressing with 'git bisect bad' each time, and when it was still bad in the end, I checked out the oldest commit in that repo, and tested that. The bibisect repo is Robinson's 44 one.

Raal, have you had any experience like this before?

[1] https://cgit.freedesktop.org/libreoffice/core/commit/?id=dea4a3b9d7182700abeb4dc756a24a9e8dea8474

[2] https://cgit.freedesktop.org/libreoffice/core/commit/?id=62ad5818884a2fc2e5780dd45466868d41009ec0

Ok, so this one is with the 43max repo. The commit is from March 28, so I'm still confused how 4.3.0.4 is free of this bug.
I might've made a mistake... at first glance, it seems related, though.

Bug also reproduced in Windows, updating OS field.


# bad: [74b89c3193673ba9897dc4a4541500ef6e8d9bf7] source-hash-8f97326bdd3f42fc82aa5e1989fd03b0af1daf64
# good: [9c392cfdfe6e9a9bce98555ea989283a957aa3ad] source-hash-fc8f44e82de4ebdd50ac5fbb9207cd1a59a927e3
git bisect start 'latest' 'oldest'
# good: [e289d9d328719fd70e9a2680fd0e4f586a97b3be] source-hash-3c0a7cf4f67720f2cca2c4eb543f838d5b644e7f
git bisect good e289d9d328719fd70e9a2680fd0e4f586a97b3be
# bad: [3e807472869ed7d72b026c12cd1e7c3cb990591f] source-hash-6390dd9777ff63ca75a088e56dd444a355439343
git bisect bad 3e807472869ed7d72b026c12cd1e7c3cb990591f
# good: [c57068b5699ab30f5721cd6a43f146c3d08d98e6] source-hash-549c3b81190d64ec23254f448ebf69520dd76da9
git bisect good c57068b5699ab30f5721cd6a43f146c3d08d98e6
# skip: [87b5a5db1a6dc620385931ebf50ad071179a94c8] source-hash-c62d31f791d7e09fdca5dd185603c78b47f19597
git bisect skip 87b5a5db1a6dc620385931ebf50ad071179a94c8
# skip: [2b5ab07da9e9748459866fd88eef213013279793] source-hash-8e4560e709fb565c69f1950387a812e543d98e22
git bisect skip 2b5ab07da9e9748459866fd88eef213013279793
# good: [3aaa8302f5cc49a157ca86c10fbe396ab0904cfb] source-hash-92ad689bcb3ad16bd35302e6ff4ee45b872c05a0
git bisect good 3aaa8302f5cc49a157ca86c10fbe396ab0904cfb
# bad: [360d446d1f8d385500543dd6ec90ab0d6e222f4c] source-hash-f4a93651bbda7750021a466e211c530c6bb02dcd
git bisect bad 360d446d1f8d385500543dd6ec90ab0d6e222f4c
# bad: [09b7c25e0e9ff110247b460d2b1f66b8f9fe547f] source-hash-993a863f45fa63d78cfa1cf46df31c85bf541463
git bisect bad 09b7c25e0e9ff110247b460d2b1f66b8f9fe547f
# bad: [f2be3d582975ff879668f91a93f6464b62379510] source-hash-1f90d06bbb448165cf4eef4235e0af244b2c7329
git bisect bad f2be3d582975ff879668f91a93f6464b62379510
# skip: [44812d0204705a231dba6a622981ef15ffec6b23] source-hash-67688d3118b1a361d5dbdaa78e918815c163d75c
git bisect skip 44812d0204705a231dba6a622981ef15ffec6b23
# skip: [dbd1667eb9259790e4d146d9cfd4b646f48078e6] source-hash-428dcc9c17118e791fb29d5b82fc317e598bb320
git bisect skip dbd1667eb9259790e4d146d9cfd4b646f48078e6
# bad: [d56d713c4c99bb0a4941f143ae6501f95b5a4b94] source-hash-df9d13dd2e754184a4c6e321b8910ee1bc0cafa1
git bisect bad d56d713c4c99bb0a4941f143ae6501f95b5a4b94
# skip: [4b1a4ac04ea7223a611e3d032201298eb938c187] source-hash-c927ceb96c17783b2a18401307f51b91d7841f33
git bisect skip 4b1a4ac04ea7223a611e3d032201298eb938c187
# skip: [f9e0120acdcc6155618152779203edaff2cc7c19] source-hash-cd648c5a35dc581ef99763159032b3662236db57
git bisect skip f9e0120acdcc6155618152779203edaff2cc7c19
# skip: [545e32e83e43cc2aa0239c696348bf1a5100dcdd] source-hash-722c82b018327c1f9578ddc533ebbb06080848eb
git bisect skip 545e32e83e43cc2aa0239c696348bf1a5100dcdd
# good: [d3bb3a80ef1dfbfbffa4cb842e30aec22c7d290a] source-hash-51765361b3b9838f7814e9cd3305f83819cb6eb0
git bisect good d3bb3a80ef1dfbfbffa4cb842e30aec22c7d290a
# bad: [af1025800ec5bd1184da14f92a494470fa7c490b] source-hash-6e61ecd09679a66060f932835622821d39e92f01
git bisect bad af1025800ec5bd1184da14f92a494470fa7c490b
# good: [8271cfb267f6385e968b660d5dd28aa73f7bd49d] source-hash-68531dbd88fda13ebcf955da454334d3511dd499
git bisect good 8271cfb267f6385e968b660d5dd28aa73f7bd49d
# good: [913b106360c31cf2cdec38fd15406b931279f773] source-hash-1ffa910582f6470af2e5ee337270dc9269436235
git bisect good 913b106360c31cf2cdec38fd15406b931279f773
# good: [e4444f5aa2b04cfe958c2eada42f8e8d45db0430] source-hash-c7190108f02921868cb617040aebdb2d22c02c1f
git bisect good e4444f5aa2b04cfe958c2eada42f8e8d45db0430
# first bad commit: [af1025800ec5bd1184da14f92a494470fa7c490b] source-hash-6e61ecd09679a66060f932835622821d39e92f01
 af1025800ec5bd1184da14f92a494470fa7c490b is the first bad commit
commit af1025800ec5bd1184da14f92a494470fa7c490b
Author: Matthew Francis <mjay.francis@gmail.com>
Date:   Thu May 28 20:34:05 2015 +0800

    source-hash-6e61ecd09679a66060f932835622821d39e92f01
    
    commit 6e61ecd09679a66060f932835622821d39e92f01
    Author:     Armin Le Grand <alg@apache.org>
    AuthorDate: Wed Mar 19 16:17:02 2014 +0000
    Commit:     Miklos Vajna <vmiklos@collabora.co.uk>
    CommitDate: Fri Mar 28 14:31:08 2014 +0100
    
        Merge back branch alg_writerframes to trunk
    
        (cherry picked from commit b635b4fa4e42053d30ab639643d2236a20243f62)

Adding Cc: to Armin Le Grand

still the same in Version: 6.1.0.0.alpha0+
Build ID: a9b202a6b7000e7af34f2a639ca207122a3968bf
CPU threads: 4; OS: Linux 4.13; UI render: default; VCL: gtk2; 
TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2017-12-26_23:09:36
Locale: nl-NL (nl_NL.UTF-8); Calc: group threaded

This commit was developed for another code base, and not merged by me. For complex changes like this, side-effects are to be expected; sadly I dont't have the cycles to deal with all the fallout. Un-Ccing myself for the while.