32710 - ghost-icons of old drag&drop actions

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect, P3)

Description

[R.K.Aa.]

Build ID 2000032109 (I've seen this one before also.)
After having toggled the location, of bookmarks with "bookmarks" - "edit
bookmars", and then closed the bookmark editor, there's a 4 to 5 minute delay,
and then the "D&D" animation (sheet of paper, slightly tilted) reappears and
animates up and down on the webpage you're on.

TO reproduce:
Go to a webpage with good contrast - like todays reported bugs in bugzilla.
Open bookmarks editor (Bookmarks/Manage bookmarks)
Drag and drop bookmarks around, some 5-10 times to get a nice effect of this.
Just shuffle around, up and down, move it.

Then sit back and *wait*. I'm on a P120 and after 4 minutes 45 seconds i get a
"replay" of the bookmark animations - silently sailing up and down and dropping
into oblivion somewhere in the browser, echoing the movements i did some 5
minutes earlyer. Kinda cute...but quite bug'ish. A timer gone astray?

Comment 1

[R.K.Aa.]

forgot: AFTER shufflling bookmarks: close the bookmark manager and *then* wait
and see..

Comment 2

[Claudius Gayle]

this came up earlier. I can't remember if it had its own bug or not. cc'ing blizzard as I believe it was his.

Comment 3

[R.K.Aa.]

the instance before this happens, there's normally also a little "unexplained"
rattling on the hard-disk. Someting is read in and then the show begins.

Comment 4

[Christopher Blizzard (:blizzard)]

Damn, that sounds like a really neat effect.  I'll look at it.

Comment 5

[Christopher Blizzard (:blizzard)]

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

Comment 6

[Christopher Blizzard (:blizzard)]

Can people try this patch and see if it fixes it?  I couldn't get any ghost
windows after applying but it just might have been luck.  Let me know if this
fixes it:

Index: nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v
retrieving revision 1.266
diff -u -r1.266 nsWindow.cpp
--- nsWindow.cpp        2000/04/15 05:44:36     1.266
+++ nsWindow.cpp        2000/04/15 06:30:44
@@ -1443,6 +1443,10 @@
 
   innerMostWidget->Release();
 
+  // before we unset the context we need to do the drag_finish.
+
+  gtk_drag_finish(aDragContext, TRUE, FALSE, aTime);
+
   // after a drop takes place we need to make sure that the drag
   // service doesn't think that it still has a context.  if the other
   // way ( besides the drop ) to end a drag event is during the leave

Comment 7

[Ben Bucksch (:BenB)]

can also be seen in mailnews.

Comment 8

[Christopher Blizzard (:blizzard)]

Did you try the patch?

Comment 9

[Ben Bucksch (:BenB)]

Yes, it did not help.

Comment 10

[Christopher Blizzard (:blizzard)]

Ok, I hacked gtk to crank the timeout down to about 4 seconds to get that window
to fly across the screen.  It's a drag timeout.  I was able to fix it with this
patch:

Index: nsWindow.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsWindow.cpp,v
retrieving revision 1.266
diff -u -r1.266 nsWindow.cpp
--- nsWindow.cpp        2000/04/15 05:44:36     1.266
+++ nsWindow.cpp        2000/04/17 01:20:52
@@ -1443,6 +1443,10 @@
 
   innerMostWidget->Release();
 
+  // before we unset the context we need to do a drag_finish
+
+  gdk_drop_finish(aDragContext, TRUE, aTime);
+
   // after a drop takes place we need to make sure that the drag
   // service doesn't think that it still has a context.  if the other
   // way ( besides the drop ) to end a drag event is during the leave

Comment 11

[Ben Bucksch (:BenB)]

oooops, I just notice, that I propably forgot to compile your first patch. No
wonder, it didn't work... :-(. Sorry. I hope, I didn't waste your time.

I just compiled your lasted patch (and commented out the former one). Will test
later.

BTW: s/drag/drop in the comment of your last patch.

Comment 12

[Christopher Blizzard (:blizzard)]

The reason why this seems to work ( aside from testing with a really short
timeout ) is that you get a drag_end signal when you do the gdk_drop_finish().
Anyway, let me know what you find.

Comment 13

[Christopher Blizzard (:blizzard)]

By the way, here's the patch that I used on gtk to test:

--- gtk+-1.2.6/gtk/gtkdnd.c.fast_timeout        Sun Apr 16 18:13:07 2000
+++ gtk+-1.2.6/gtk/gtkdnd.c     Sun Apr 16 18:16:13 2000
@@ -119,7 +119,7 @@
   gint               drop_x, drop_y; /* Position of drop */
 };
 
-#define DROP_ABORT_TIME 300000
+#define DROP_ABORT_TIME 3000
 
 #define ANIM_STEP_TIME 50
 #define ANIM_STEP_LENGTH 50
@@ -2809,6 +2809,8 @@
 {
   GtkDragSourceInfo *info = data;
   guint32 time = GDK_CURRENT_TIME;
+
+  g_print("gtk_drag_abort_timeout\n");
 
   GDK_THREADS_ENTER ();

Comment 14

[Ben Bucksch (:BenB)]

ALthough I didn't use you latest test-patch, I didn't see the bug anymore. I'll

run a bit more, but I think, it is fixed.

Comment 15

[Christopher Blizzard (:blizzard)]

Please ignore the spam.  Changing address.

Comment 16

[Christopher Blizzard (:blizzard)]

bustage from my reassign

Comment 17

[Christopher Blizzard (:blizzard)]

I'm going to check this in when I get the chance, then.

Comment 18

[Christopher Blizzard (:blizzard)]

Checked in.

Comment 19

[Christopher Blizzard (:blizzard)]

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

Comment 20

[Claudius Gayle]

marking this VERIFIED