Reproduced.

Win 7 64-bit Version: 4.4.0.0.alpha2+
Build ID: b021b5983c62e266b82d9f0c5c6d8d8900553827
TinderBox: Win-x86@42, Branch:master, Time: 2014-11-12_00:19:18

Ubuntu 14.10 64-bit Version: 4.4.0.0.alpha2+
Build ID: 1c526c9ddda5d52f7a4db5655a4ec60b8c62835c
TinderBox: Linux-rpm_deb-x86_64@46-TDF-dbg, Branch:master, Time: 2014-11-11_23:20:41

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.michaelsen@canonical.com>
Date:   Sun May 11 10:33:38 2014 +0000

    source-hash-b634aa656a74e1f8ebeaf8a9092829294c49171d
    
    commit b634aa656a74e1f8ebeaf8a9092829294c49171d
    Author:     Chris Sherlock <chris.sherlock79@gmail.com>
    AuthorDate: Fri Feb 7 22:50:28 2014 +1100
    Commit:     Caolán McNamara <caolanm@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 <caolanm@redhat.com>
        Tested-by: Caolán McNamara <caolanm@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

The behaviour seems to have changed as of the below commit.

Adding Cc: to mstahl@redhat.com. Could you possibly take a look at this? Thanks


commit 38d0047da7f964c862360b48d88cc869ad376b6b
Author: Michael Stahl <mstahl@redhat.com>
Date:   Fri Feb 7 18:25:39 2014 +0100

    related: fdo#74230: Area tab page: prevent default gradient/hatch/bitmap
    
    The Area dialog for shapes unfortunately makes it possible to set
    gradients/hatching/bitmap that uses the default items in the
    SfxItemPool.  These items however cannot be stored to ODF files, since
    these are represented as elements, not as attributes on a
    style:default-style; what we get for defaults is a somewhat silly
    draw:fill="hatch" without an draw:fill-hatch-name.
    So prevent the dialog from creating them by forcing a selection of an
    entry in the list.
    
    Change-Id: I67cc6dbbf7b491f06d094d4de1e9c3ffe79b01f5