GNOME Bugzilla – Bug 108166
Menu panel switches to drag'n'drop
Last modified: 2014-03-24 02:22:58 UTC
Sometimes, when using the menu of the menu panel, the menu switches to "drag and drop mode", i.e. instead of highlighting the current item, the cursor has a cross shape and drags something. How to reproduce: click on the "Applications" menu with the left mouse button, and never release it. Open a big submenu (I'm using the "Internet" submenu) and wander up and down in the submenu a few times (still without releasing the left mouse button). Eventually the menu will switch to "drag and drop" mode. This bug has been observed in all 2.x releases.
Are your sure your mouse isn't generating some release/press events while you have it held?
If it is, then my mouse is too. I am seeing this with a Microsoft mouse, and I _think_ I saw it with the Logitec mouse I used before. I have never been able to reproduce it reliably, though.
At first I thought it was my mouse. Then I changed it for a new one. Now I'm pretty sure it's not.
If someone can reproduce, the way to debug would be to put a break in gtk_drag_begin() and see why it gets triggered.
+ Trace 37299
Bug 115263 (and its duplicates) may be a duplicate of this bug, but I'm not sure.
- If this was the mouse generating spurious press/release events you would generally expect to see random activations of menu items, not drags. - The backtrace doesn't make sense to me. _gdk_drag_source_handle_event() doesn't call gdk_drag_begin(). Is this a case of libtool removing the wrong symbols? Xavier, if you compiled gtk+ yourself, could you try re-generating the backtrace with the line LIBTOOL_EXPORT_OPTIONS='-export-symbols-regex "^[[^_]].*"' in gtk+'s configure.in changed to LIBTOOL_EXPORT_OPTIONS=#'-export-symbols-regex "^[[^_]].*"' ?
Reproduction instructions: Click on "Applications" Click on "Help" [Close the resulting help viewer] Press and hold on "Applications" Drag down to help. The panel will switch to drag mode.
Backtrace:
+ Trace 40060
Additional information: (gdb) print event->type $12 = GDK_MOTION_NOTIFY (gdb) print *site $14 = {start_button_mask = 768, target_list = 0x82b06c8, actions = GDK_ACTION_COPY, icon_type = GTK_IMAGE_EMPTY, icon_data = { pixmap = {pixmap = 0x0}, pixbuf = {pixbuf = 0x0}, stock = { stock_id = 0x0}}, icon_mask = 0x0, colormap = 0x0, state = 0, x = 143, y = 16} (gdb) print event->motion $15 = {type = GDK_MOTION_NOTIFY, window = 0x82be9d0, send_event = 0 '\0', time = 5392983, x = 39, y = 7, axes = 0x0, state = 256, is_hint = 0, device = 0x80da600, x_root = 444, y_root = 534} (gdb) print *widget $16 = {object = {parent_instance = {g_type_instance = {g_class = 0x8170420}, ref_count = 6, qdata = 0x82b1b58}, flags = 2164704}, private_flags = 3600, state = 2 '\002', saved_state = 0 '\0', name = 0x0, style = 0x81da940, requisition = {width = 73, height = 20}, allocation = { x = 0, y = 440, width = 222, height = 20}, window = 0x82b4de0, parent = 0x82a2250}
Note the difference between the x,y in event->motion and the x,y in site. The problem is that clicking on a menu item generates a press event, but no corresponding release event. This means that site->state doesn't get properly reset by the code in the BUTTON_RELEASE branch of the switch in gtk_drag_source_event_cb(). So the problem is probably somewhere in the menu event code. (Why do I have this feeling of deja vu?)
*** Bug 124599 has been marked as a duplicate of this bug. ***
I can't reproduce this anymore with recent HEAD. Kris, do you think this could have been fixed by the table menu patch?
Hmm, I didn't really touch the event handling code in GtkMenu* apart from the keynav parts.
FWIW, I still observe this bug with GNOME2.4 (GTK+2.2)
I can confirm this behavior on Gnome 2.4.0, Gentoo Linux, gcc 3.2.3 20030422. It's always reproducible per Søren's instructions.
A useful thing for someone to do would be to find out if - it is still reproducible with HEAD gtk+ - if not, exactly when did it stop happening
It is still reproducible with current HEAD, but for a while it didn't happen for some reason. The problem that Owen explains in bug 93085 is almost certainly also what causes this bug.
Bug 92085 actually.
*** Bug 134917 has been marked as a duplicate of this bug. ***
This bug is no longer reproduceable as of gtk+ 2.6.1. I believe it still existed in 2.6.0.
There's no such thing as gtk+ 2.6.1 yet. I assume you mean gtk+ 2.4.1 (or is it gnome 2.6.1 ?)
Oops, that's gtk+ 2.4.1 with gnome 2.6.1.
Mass changing gtk+ bugs with target milestone of 2.4.2 to target 2.4.4, as Matthias said he was trying to do himself on IRC and was asking for help with. If you see this message, it means I was successful at fixing the borken-ness in bugzilla :) Sorry for the spam; just query on this message and delete all emails you get with this message, since there will probably be a lot.
In comment 18, it should read bug 92085.
This problem persists in Gnome 2.8.3. Easily reproducible.
*** Bug 173131 has been marked as a duplicate of this bug. ***
*** Bug 172630 has been marked as a duplicate of this bug. ***
*** Bug 313565 has been marked as a duplicate of this bug. ***
closign out ancient bugs