GNOME Bugzilla – Bug 127586
big totem mouse error
Last modified: 2004-12-22 21:47:04 UTC
Distribution: Red Hat Linux release 9 (Shrike) Package: totem Severity: normal Version: GNOME2.4.1 unspecified Gnome-Distributor: GNOME.Org Synopsis: big totem mouse error Bugzilla-Product: totem Bugzilla-Component: general Bugzilla-Version: unspecified Description: Description of Problem: when dragging and dropping from the topem video windows to itself. the mouse becomes inactive ( still moves ) and the keyboard no longer responds with gnome. mostly this happens by accidently left-clicking inside the video window and this makes the entire gnome desktop unusable . Steps to reproduce the problem: 1. open totem, play a video 2. click and move the mouse inside the video area 3. try and use the desktop, Actual Results: try and close the program. do anything from gui ( it wont work ) it can happen in fullscreen as well as windowed mode Expected Results: drag and drop would be ignored inside its own window or come up with an error saying ( you cant put something inside itself ) How often does this happen? everytime the steps are taken Additional Information: ------- Bug moved to this database by unknown@bugzilla.gnome.org 2003-11-20 23:55 ------- The original reporter (Andrewf1@Fitzsimon.com.au) of this bug does not have an account here. Reassigning to the exporter, unknown@bugzilla.gnome.org. Reassigning to the default owner of the component, hadess@hadess.net.
I can't reproduce that problem.
I still can't reproduce the problem. Can you give a bit more details, such as the version of GTK+ used, and a backtrace of the hang?
I have seen this bug. I think its root is a bug in gtk+. A work around was developed for mozilla. http://bugzilla.mozilla.org/show_bug.cgi?id=183370 The symptoms of this bug in mozilla is the same as the bug in totem. Cursor changes to a DND cursor and under unlikely circumstances it doesn't change back. If you kill totem everything is back to normal.
this is a dupe of #122120 .
ignore that message it was a mistake
This looks like a toolkit issue.
I see no reason to think it's a GTK+ problem a-priori, and certainly we can't debug this at the GTK+ level. It's certainly possible for an app to cause stuck drags by hiding some events from GTK+.
Should be fixed now. 2004-01-04 Bastien Nocera <hadess@hadess.net> * src/bacon-video-widget-xine.c: (bacon_video_widget_button_press): Don't hide mouse button presses from GTK+ (Closes: #127586)