https://bugs.freedesktop.org/show_bug.cgi?id=82784

tmacalp <tmac...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |regression
           Priority|medium                      |high
                 CC|                            |tmac...@gmail.com
           Hardware|x86 (IA32)                  |All
         Whiteboard|                            |bibisected
                 OS|Windows (All)               |All

--- Comment #2 from tmacalp <tmac...@gmail.com> ---
Damn, I just typed out a full bug report before finding this one!  I'll paste
here, since it appears to be the same bug.  My steps for getting the object
with a custom image background are a bit different, and not really relevant to
this report, but I'll leave them in. :)

Since this is obviously a regression from a previously working behavior, I've
upping the severity from medium to high.  I tested this under various
32bit/64bit linux distributions, so I'll change from being 32bit MS Windows
only to hardware all/all.


Description:
As of LO 4.2.x, if you create a basic draw object and attempt to insert a
picture with that shape selected, Draw will apply a tiled bitmap of that image
to the selected draw object.  If you look at the object's Area properties,
you'll notice that there is an applied bitmap to the object, but that bitmap
doesn't show in the bitmap list.

In 4.2.0.4, this weird behavior actually kind of worked.  When you visit the
Area dialog's "Area" tab, Fill would be set to "Bitmap" and none of the items
in the bitmap list would be selected.  The preview at the bottom would show
your custom image.  This allowed you to actually change attributes (enable
autofit instead of tile, change offset, size, etc...).  And you could then
click OK to apply.

At some point after 4.2.0.4, this behavior was broken, so that whenever you
open the "Area" tab, the bitmap style "Blank" is defaulted to being selected. 
There is no way to choose your custom temporary bitmap style in the dialog,
since it doesn't appear in the list.  So any changes you make will also apply
the new bitmap style of Blank.  So you end up with a White bitmapped shape.

Steps to reproduce:
1. Create new Drawing
2. Use rectangle tool to draw a rectangle
3. Insert -> Image from file
4. Select an image and click Open
5. Format -> Area

Expected:
The Area dialog should appear with our custom image in the preview window and
nothing selected in the bitmap list.

Actual:
The Area dialog appears with just white showing in the preview window and
"Blank" selected in the bitmap list.  Because of this, our custom bitmapped
object will be forced to become white.

6. Click the "Tile" checkbox to disable "Tile" and enable "AutoFit"
7. Click OK

Expected:
Our object with a custom bitmap background should now be autofit to our object.

Actual:
Our object is now white.

Notes:
The most elegant way of handling this issue would be to actually to enhance the
dialog to SHOW our temporary image-generated bitmap in the list of selectable
bitmaps for this object.  We don't want to actually add this image to our
permanent list of bitmaps, though.  Maybe in this case, we could have an item
in the list titled "Applied bitmap," "Current bitmap," or something similar.

It would also be a nice enhancement if there was a way to choose a temporary
image bitmap in the Area dialog without adding it to the permanent bitmap list.
 That should probably be another enhancement request, though.

The easy fix is to simply revert to the old behavior of having nothing actually
selected.

I've bibisected:

ce550d732fd43380870f273e6674894d5bb1cdf2 is the first bad commit
commit ce550d732fd43380870f273e6674894d5bb1cdf2
Author: Bjoern Michaelsen <bjoern.michael...@canonical.com>
Date:   Sun May 11 10:33:38 2014 +0000

    source-hash-b634aa656a74e1f8ebeaf8a9092829294c49171d

    commit b634aa656a74e1f8ebeaf8a9092829294c49171d
    Author:     Chris Sherlock <chris.sherloc...@gmail.com>
    AuthorDate: Fri Feb 7 22:50:28 2014 +1100
    Commit:     Caolán McNamara <caol...@redhat.com>
    CommitDate: Fri Feb 7 20:16:23 2014 +0000

        Remove commented code in OutputDevice::ReMirror

        The following code was reimplemented in a cleaner fashion some time
        ago. However, it was just commented out and never removed. There is
        no need for it now, so removing. It's in the DVCS if it's really
        needed :-)

        Change-Id: Ia7d3c480ba70ccbd8dcf2808d9b712499c4cef4f
        Reviewed-on: https://gerrit.libreoffice.org/7913
        Reviewed-by: Caolán McNamara <caol...@redhat.com>
        Tested-by: Caolán McNamara <caol...@redhat.com>

:100644 100644 05874cf3764db72071b0d1b5d25bab8c7b5f7fb0
253114e5235f294b17b079bdbbc5aeeaae0e15b2 M      ccache.log
:100644 100644 b6d22eb23af685e0bf6f87ef3f5ef02a999ddc19
e1a110f455c5d638b61505bc8751b78557282e98 M      commitmsg
:100644 100644 a958005a2c4cd7a54b08bd25ec524930b3f5f0d3
bc63e7f72f8898a76d822c221a1fc5d1c2c91cf5 M      make.log
:040000 040000 fb4d7c258fc0eadfaeae60b239d3efd2c55e4e26
e2de3407c4f93021f77aae11d25f83026b900b1f M      opt


$ git bisect log
git bisect start 'last43onmaster' 'last42onmaster'
# bad: [4fcd68ce4979f85fda4568f4b419a4b41d07345f]
source-hash-2c4621c87ed3a7b19de195c21494c9a381e72b2e
git bisect bad 4fcd68ce4979f85fda4568f4b419a4b41d07345f
# good: [0d4c20a601a3cfff27d6685d0e81463086bd9d74]
source-hash-f1b1e73227471192682d303a58618ca8bd65a74d
git bisect good 0d4c20a601a3cfff27d6685d0e81463086bd9d74
# bad: [3c72d6d27e2a0c420f74941355400b0834c550bb]
source-hash-c30677731c55688c764a669ecea1b1c4d17ae57d
git bisect bad 3c72d6d27e2a0c420f74941355400b0834c550bb
# good: [1f32fb58159d7f43a4bcb838765261d5274cbf38]
source-hash-4a169e4203c10ec8f76b9bcb33882c82b65c7bab
git bisect good 1f32fb58159d7f43a4bcb838765261d5274cbf38
# good: [1da81d12775c421b7a04cd3a579fa555442c35f6]
source-hash-ac01fd51822dc006abec578d61d66f7a169c19cb
git bisect good 1da81d12775c421b7a04cd3a579fa555442c35f6
# bad: [273a2f4e453564a9aad29b4e4fb0d3c46938bb9e]
source-hash-863f1bfca71a5eb084931b49393fb7a9c5a0deaf
git bisect bad 273a2f4e453564a9aad29b4e4fb0d3c46938bb9e
# bad: [62e28acf6d832fb1ad030889541aad3f626612ba]
source-hash-12e0102f39ee3a0398a4369bbc4af4ea0f51ca14
git bisect bad 62e28acf6d832fb1ad030889541aad3f626612ba
# bad: [ce550d732fd43380870f273e6674894d5bb1cdf2]
source-hash-b634aa656a74e1f8ebeaf8a9092829294c49171d
git bisect bad ce550d732fd43380870f273e6674894d5bb1cdf2
# first bad commit: [ce550d732fd43380870f273e6674894d5bb1cdf2]
source-hash-b634aa656a74e1f8ebeaf8a9092829294c49171d

-- 
You are receiving this mail because:
You are the assignee for the bug.
_______________________________________________
Libreoffice-bugs mailing list
Libreoffice-bugs@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs

Reply via email to