540474 - window controls do not respond / become unresponsive after dragging a bookmark from Bookmarks Menu to desktop / other application

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

Using Ubuntu 9.10

STR:
1. Create a bookmark in the bookmark menu
2. Open the bookmark menu
3. Drag it to the desktop

Expected: link created on desktop, everything else to work normally
Actual: link is created on the desktop, the window controls (for moving the Firefox window, maximizing, minimizing and closing) stop working, and it's impossible to return focus to the window manager

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

Same thing happens when dragging from Bookmark Menu to another application like a text editor or email program.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

Whimboo notes that the first time you drag to the desktop, the desktop shortcut doesn't show up properly on the desktop though it does in the File Explorer. To me this indicates that we're not co-ordinating properly with the desktop in terms of "returning" from the drag operation from the menu.

This is pretty bad, despite it being a low frequency use case.

Comment 3

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Also happens with Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.8pre) Gecko/20100110 Shiretoko/3.5.8pre

It doesn't matter how often I try that. At any time the link is not visible on the desktop while mc is showing it with 444 permissions.

Comment 4

[Neil Deakin]

Don't see this on trunk or 3.6. Does this only apply to 3.5?

Comment 5

[Henrik Skupin [:whimboo][⌚️UTC+1]]

No. As reported 3.6 suffers from that too.

Comment 6

[Karl Tomlinson (:karlt)]

Since GTK 2.18, it no longer grabs the keyboard for its drag nor releases after.

What happens here is:
1. We grab the keyboard in CaptureRollupEvents when opening the menu.
2. The drag begins (which prior to GTK 2.18 would steal the keyboard grab).
3. The bookmarks menu rolls up, but the grab is not released in
   CaptureRollupEvents(doCapture=false) because it was assumed that the drag
   now had the grab).
4. GTK does not remove the grab on drop because it never took the keyboard grab.

One nasty symptom is that, even when typing after focusing on another app, keyboard input continues to go into the Firefox when the drag was initiated.

This would be fixed by the patch in bug 545429 to remove the troublesome GrabKeyboard in CaptureRollupEvents.

Comment 7

[Karl Tomlinson (:karlt)]

Bug 407633 is related, affecting the close button, but effects are localized to the Gecko app.