Closed Bug 540474 Opened 10 years ago Closed 9 years ago

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

Categories

(Core :: Widget: Gtk, defect)

x86
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b12

People

(Reporter: beltzner, Assigned: karlt)

References

Details

(Whiteboard: [3.6.x][3.6rc2][fixed in bug 545429])

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
Same thing happens when dragging from Bookmark Menu to another application like a text editor or email program.
Summary: window controls do not respond / become unresponsive after dragging a bookmark from Bookmarks Menu to desktop → window controls do not respond / become unresponsive after dragging a bookmark from Bookmarks Menu to desktop / other application
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.
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.
Version: 3.6 Branch → 3.5 Branch
Component: Menus → Bookmarks & History
QA Contact: menus → bookmarks
Don't see this on trunk or 3.6. Does this only apply to 3.5?
No. As reported 3.6 suffers from that too.
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.
Assignee: nobody → karlt
Component: Bookmarks & History → Widget: Gtk
Depends on: 545429
Product: Firefox → Core
QA Contact: bookmarks → gtk
Version: 3.5 Branch → Trunk
Bug 407633 is related, affecting the close button, but effects are localized to the Gecko app.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [3.6.x][3.6rc2] → [3.6.x][3.6rc2][fixed in bug 545429]
Target Milestone: --- → mozilla2.0b12
You need to log in before you can comment on or make changes to this bug.