Thanks for your bug report!
Unfortunately, I am unable to entirely understand your problem, probably due to
my limited English knowledge. Could you please clarify what the issue with this
dialog is?

Ok I will try this in two different languages:

German:
-------
a) Schau Dir die drei Dialoge einmal an.
b) Dialog 1) Scroll nach ganz unten und versuch dann Terracotta irgendwo hin zu
dragen. Das geht hier nicht, mit den Elementen ganz oben geht das (vor dem
Scrollen).
c) Das Gleiche mit Dialog 2) (Onyx) und 3) (Important).

English:
--------
a) Please have a look at the three Dialogs.
b) Dialog 1) Scroll at the bottom and then try to drag Terracotta somewhere.
That doesn't work here except the elements at the top (before you scroll)
c) The same happens with Dialog 2) (Onyx) and 3) (Important).

Created attachment 49272 [details]
Dialog 1

Created attachment 49273 [details]
Dialog 2

Created attachment 49274 [details]
Dialog 3

Eek! Thanks for pointing this out. Might also be EelImageTable bugginess. I
wonder why the emblem sidebar uses EelScrolledWrapTable in contrast to this
dialog. Alex, any ideas?

Is this the same as I reported in bug #311291? Please have a look at attachment
#49593 [details] which I added in bug #311291 comment #1 showing a flash movie which
describes the bug.

Yes, that's an identical bugreport.

Okay. The difference between this bug and my 311291 is, that 308996 is about
CVS. I don't use CVS.

> Okay. The difference between this bug and my 311291 is,
> that 308996 is about CVS. I don't use CVS.

You are of course right, but nontheless the tarballs are usually made out of the
CVS modules :)

This problem exists for quite some longer time now, even longer than the time
where I finally reported it. So chances seem to be realistic that you got this
bug too in one of your 2.10.x tarballs.

*** Bug 311291 has been marked as a duplicate of this bug. ***

but is still reproductuble with today's CVS.

After investigating a bit deeper into this issue I came along to this piece of
code in the file "nautilus-property-browser.c" and came to the conclusion that
this is more an XServer related issue rather than one from nautilus. But I am
not sure whether this is a XServer bug or a behavior that was intended.

-------------------------------------------------------------------------
static void
element_clicked_callback (GtkWidget *image_table,
			  GtkWidget *child,
			  const EelImageTableEvent *event,
			  gpointer callback_data)
{
	....

	/* compute the offsets for dragging */
	if (strcmp (drag_types[0].target, "application/x-color")) {
		/* it's not a color, so, for now, it must be an image */
		/* .. with the category to handle the "reset" case properly */
		char * save_category = property_browser->details->category;
		if (eel_strcmp (property_browser->details->category, "colors") == 0) {
			property_browser->details->category = "patterns";
		}
		pixbuf = make_drag_image (property_browser, element_name);
		property_browser->details->category = save_category;
		x_delta = gdk_pixbuf_get_width (pixbuf) / 2;
		y_delta = gdk_pixbuf_get_height (pixbuf) / 2;
	} else {
		pixbuf = make_color_drag_image (property_browser, element_name, TRUE);
		gdk_window_get_position (GTK_VIEWPORT (image_table->parent)->bin_window,
					 &scroll_offset_x,
					 &scroll_offset_y);
		x_delta = event->x - child->allocation.x - scroll_offset_x;
		y_delta = event->y - child->allocation.y - scroll_offset_y;

		g_print ("x:%d, y:%d\n", scroll_offset_x, scroll_offset_x);
	}

	....
}
-------------------------------------------------------------------------

Specially this part of above code snipplet should be of our interest. If we deal
with the dialogs (small sized one) and drag & drop around the items inside the
EelImageTable then we can drag & drop only those that are visible, if we now
totally enlarge the window maybe so we see all items at all then we can drag &
drop all of them correctly, but as soon as we use the scrollbar at the side we
need to get the scroll_offset for X and Y and need to reduce them which gives us
the results of x_delta and y_delta.

-------------------------------------------------------------------------
gdk_window_get_position (GTK_VIEWPORT (image_table->parent)->bin_window,
					 &scroll_offset_x,
					 &scroll_offset_y);

x_delta = event->x - child->allocation.x - scroll_offset_x;
y_delta = event->y - child->allocation.y - scroll_offset_y;
-------------------------------------------------------------------------

Now from reading the gdk_window_get_position (); API reference we get this comment.

http://developer.gnome.org/doc/API/2.0/gdk/gdk-Windows.html#gdk-window-get-position

"Obtains the position of the window as reported in the most-recently-processed
GdkEventConfigure. Contrast with gdk_window_get_geometry() which queries the X
server for the current window position, regardless of which events have been
received or processed."

So my guess here is that whenever this queries the XServer then wrong values are
returned, these wrong values cause the whole drag & drop stuff to completely
mess up because it is not able to get correct scroll_offset values.

Created attachment 49771 [details] [review]
Proposed patch

I've also submitted this patch to nautilus-list [1] for review.

[1] http://mail.gnome.org/archives/nautilus-list/2005-July/msg00284.html

*** Bug 311657 has been marked as a duplicate of this bug. ***

Created attachment 50292 [details] [review]
Proposed nautilus glue

Makes the property browser *not* break for colors. Thanks to Martin Wehner for
pointing this out.

*** Bug 317704 has been marked as a duplicate of this bug. ***

Status is fixed.. how can I fix my nautilus? I don't get it.

You can fix this by upgrading Nautilus to 2.12 or later (2.12.1 suggested).

*** Bug 319016 has been marked as a duplicate of this bug. ***

*** Bug 324780 has been marked as a duplicate of this bug. ***