Closed Bug 183370 Opened 22 years ago Closed 21 years ago

gtk2 Mouse pointer changes when dragging text and locks up X

Categories

(Core :: XUL, defect)

x86
Linux
defect
Not set
critical

Tracking

()

RESOLVED FIXED

People

(Reporter: mccutcjs, Assigned: blizzard)

References

Details

(Keywords: hang)

Attachments

(1 file, 3 obsolete files)

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021127
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2) Gecko/20021127

I have a bad habit of continually selecting text and clicking. Sometimes while
I am doing this, the X cursor changes to a right angle pointing to the
upper left (The drag and drop cursor) with an X inside the angle. Then X locks
up and I can't do anything, I can switch to the console and kill galeon-bin
and then X returns to normal. I assume this has something to do with the
gtk2 embedding widget.

Reproducible: Sometimes

Steps to Reproduce:
1.Keep selecting text and dragging it.

Actual Results:  
X locks up with the cursor being a drag and drop cursor with an X instead
of a document icon in the right angle.

Expected Results:  
Continue to function.
Keywords: hang
Blocks: gtk2
Summary: Mouse pointer changes when dragging text and locks up X → gtk2 Mouse pointer changes when dragging text and locks up X
(gdb) thread 1
[Switching to thread 1 (Thread 16384 (LWP 7938))]#0  0x40b17320 in poll ()
   from /lib/libc.so.6
(gdb) bt
#0  0x40b17320 in poll () from /lib/libc.so.6
#1  0x409ad73f in g_main_context_poll (context=0x814abd8, timeout=55638,
    priority=2147483647, fds=0x826f060, n_fds=10) at gmain.c:2560
#2  0x409accfa in g_main_context_iterate (context=0x814abd8, block=1,
    dispatch=1, self=0x813dab8) at gmain.c:2237
#3  0x409ad3ff in g_main_loop_run (loop=0x8227238) at gmain.c:2462
#4  0x40720a4f in bonobo_main () at bonobo-main.c:290
#5  0x0807601a in main (argc=2, argv=0xbffffc24) at galeon-main.c:158

(gdb) thread 2
[Switching to thread 2 (Thread 32769 (LWP 7941))]#0  0x40b17320 in poll ()
   from /lib/libc.so.6
(gdb) bt
#0  0x40b17320 in poll () from /lib/libc.so.6
#1  0x40941daa in __pthread_manager () from /lib/libpthread.so.0

(gdb) thread 3
[Switching to thread 3 (Thread 16386 (LWP 7942))]#0  0x40b17320 in poll ()
   from /lib/libc.so.6
(gdb) bt
#0  0x40b17320 in poll () from /lib/libc.so.6
#1  0x4014cae0 in PR_OpenDir () from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#2  0x4014cc14 in PR_Poll () from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#3  0x40e9bee5 in NSGetModule ()
   from /opt/garnome/lib/mozilla-1.2/components/libnecko.so
#4  0x400d6e8e in nsThread::Main ()
   from /opt/garnome/lib/mozilla-1.2/libxpcom.so
#5  0x4014dc6d in PR_Select () from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#6  0x4094206f in pthread_start_thread () from /lib/libpthread.so.0

(gdb) thread 4
[Switching to thread 4 (Thread 32771 (LWP 7943))]#0  0x40a80ce2 in sigsuspend
    () from /lib/libc.so.6
(gdb) bt
#0  0x40a80ce2 in sigsuspend () from /lib/libc.so.6
#1  0x409446df in __pthread_wait_for_restart_signal ()
   from /lib/libpthread.so.0
#2  0x40941173 in pthread_cond_wait () from /lib/libpthread.so.0
#3  0x40148ee2 in PR_WaitCondVar ()
   from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#4  0x40ea7a53 in NSGetModule ()
   from /opt/garnome/lib/mozilla-1.2/components/libnecko.so
#5  0x40ea7500 in NSGetModule ()
   from /opt/garnome/lib/mozilla-1.2/components/libnecko.so
#6  0x400d6e8e in nsThread::Main ()
   from /opt/garnome/lib/mozilla-1.2/libxpcom.so
#7  0x4014dc6d in PR_Select () from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#8  0x4094206f in pthread_start_thread () from /lib/libpthread.so.0

(gdb) thread 5
[Switching to thread 5 (Thread 49156 (LWP 7944))]#0  0x40af55f1 in nanosleep ()
   from /lib/libc.so.6
(gdb) bt
#0  0x40af55f1 in nanosleep () from /lib/libc.so.6
#1  0x4094480a in __pthread_timedsuspend_new () from /lib/libpthread.so.0
#2  0x409413c1 in pthread_cond_timedwait_relative () from /lib/libpthread.so.0
#3  0x4094154e in pthread_cond_timedwait () from /lib/libpthread.so.0
#4  0x40148cec in PR_Unlock () from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#5  0x40148ef6 in PR_WaitCondVar ()
   from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#6  0x400d9fe6 in TimerThread::Run ()
   from /opt/garnome/lib/mozilla-1.2/libxpcom.so
#7  0x400d6e8e in nsThread::Main ()
   from /opt/garnome/lib/mozilla-1.2/libxpcom.so
#8  0x4014dc6d in PR_Select () from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#9  0x4094206f in pthread_start_thread () from /lib/libpthread.so.0

(gdb) thread 6
[Switching to thread 6 (Thread 245765 (LWP 7971))]#0  0x40a80ce2 in sigsuspend
    () from /lib/libc.so.6
(gdb) bt
#0  0x40a80ce2 in sigsuspend () from /lib/libc.so.6
#1  0x409446df in __pthread_wait_for_restart_signal ()
   from /lib/libpthread.so.0
#2  0x40941173 in pthread_cond_wait () from /lib/libpthread.so.0
#3  0x40148ee2 in PR_WaitCondVar ()
   from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#4  0x400d7c15 in nsThreadPool::GetRequest ()
   from /opt/garnome/lib/mozilla-1.2/libxpcom.so
#5  0x400d8484 in nsThreadPoolRunnable::Run ()
   from /opt/garnome/lib/mozilla-1.2/libxpcom.so
#6  0x400d6e8e in nsThread::Main ()
   from /opt/garnome/lib/mozilla-1.2/libxpcom.so
#7  0x4014dc6d in PR_Select () from /opt/garnome/lib/mozilla-1.2/libnspr4.so
#8  0x4094206f in pthread_start_thread () from /lib/libpthread.so.0
Thats the stacks for all the threads when I attach to the process after it
has locked up.
Actually I just came up with a way to reproduce this, just keep clicking into
and out of mozilla/galeon. And I just saw a bug recently about crashing
on focus in/out of mozilla. This may be the same bug! I hope it is this has
been so annoying!
Status: UNCONFIRMED → ASSIGNED
Component: Embedding: GTK Widget → XP Toolkit/Widgets
Ever confirmed: true
Is this a possible dupe of 169108?
*** Bug 169108 has been marked as a duplicate of this bug. ***
Attached patch patch (obsolete) — Splinter Review
The bug is due to time sequence disorder. Porting it from gtk1.2. We still need
this.
Attachment #109629 - Flags: review?(blizzard)
Comment on attachment 109629 [details] [diff] [review]
patch


>+    if (sTimeCBSet == PR_FALSE) {
>+        nsCOMPtr<nsIDragService> dragService = do_GetService(kCDragServiceCID);
>+        if (!dragService) {
>+#ifdef DEBUG
>+            g_print("*** warning: failed to get the drag service. this is a _bad_ thing.\n");
>+#endif

Change this to just be:

if (dragService) {
  [ rest of function that uses the drag service ]
}

instead of giving that warning.

>     Window              mOldFocusWindow;
> 
>+    // the event handling code needs to let us know the time of the last event
>+    static void SetLastEventTime(guint32 aTime);
>+    static void GetLastEventTime(guint32 *aTime);

Try to use the same indenting as the functions above, if possible.

>+
> #ifdef USE_XIM
>     void               IMEComposeStart(void);
>     void               IMEComposeText(const PRUnichar *aText,
>@@ -300,6 +304,11 @@
>     guint              mDragMotionTime;
>     guint              mDragMotionTimerID;
>     nsCOMPtr<nsITimer> mDragLeaveTimer;
>+
>+    // this is the last time that an event happened.  we keep this
>+    // around so that we can synth drag events properly
>+    static guint32 sLastEventTime;
>+    static PRBool sTimeCBSet;

Same here, please use the same indenting as the member variables above.
Attachment #109629 - Flags: review?(blizzard) → review-
Attached patch patch (obsolete) — Splinter Review
patch according to blizzard's comments.
In my patch, I only set the last event time while a motionnotify is comming. I
assume only motionnotify could trigger the dnd to begin. Is that right?
Attachment #109629 - Attachment is obsolete: true
In the old code we were stting the last event time for every single X event that
came across the wire.  So, I'm not sure if we're sampling for the right time or not.

I would need to play with this in order to get it completely correct, I think. 
However, if what you have seems to work well we can use it.
I found in nsEventStateManager.cpp that only NS_MOUSE_MOVE calles
GenerateDragGesture which will eventually trigger InvokeDragSession. It would be OK.
One thing I concern is that the names of the methods are not so meanful because
it's only the last motion notify event. Should I change it or keep it for the
other event may use in the future?
Yeah, good idea.  Go ahead and change the name of the function.
Attached patch patch (obsolete) — Splinter Review
method name changed patch
Attachment #109702 - Attachment is obsolete: true
Yo, why isn't this in yet?
Attachment #109805 - Flags: review?(blizzard)
This is a really, really nasty bug- it doesn't just hang mozilla- for the
'average' user who doesn't know how to get to a virtual console it requires a
reboot. Can we get it applied, please? 
Comment on attachment 109805 [details] [diff] [review]
patch

way to complicated, even if it is ported from my original patch
Attachment #109805 - Flags: review?(blizzard) → review-
Attached patch patchSplinter Review
smaller patch that does basically the same thing
Attachment #109805 - Attachment is obsolete: true
Checked in.
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
*** Bug 194074 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: