Closed Bug 500081 Opened 11 years ago Closed 8 years ago

Can't start dragging a menu toolbarbutton with type menu after the popup has been opened

Categories

(Core :: Widget: Gtk, defect)

All
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla13

People

(Reporter: mak, Assigned: karlt)

References

(Depends on 1 open bug)

Details

Attachments

(4 files)

On Bookmarks toolbar we support dragging toolbarbuttons with type "menu", but we have to workaround a dragging issue on Linux.
Popups are opened on mousedown, on this platform as soon as the popup opens we're unable to start a drag operation, while this is not a problem on Win or Mac.

So we have delay the menu.open = true on mousedown, and decide based on gesture if the user wants to drag (in such a case we stop opening) or to open (in such a case we prevent the drag). Previously we were forcing all users to hold down SHIFT to allow a drag, due to this issue (indeed i thought this bug was already filed, but can't find it atm).
If Linux would work as other platforms, we could simply let the popup open, and see later if we want to drag.
Blocks: 495675
The current delay before opening the popup is probably too short.  I actually found this bug while searching for one about why I couldn't drag a bookmarks folder on Linux.  With much effort I can now manage to initiate a drag about 1 time in 10.  The timer seems to be 300ms but there certainly doesn't seem to be that much time to start the drag.  Perhaps it takes a good fraction of that time for Firefox to register that a drag is starting, leaving very little window?
Can the popup be closed before initiating the drag?
See Also: → 721762
The drag fails because it is using a timestamp that is older than the time of the pointer grab on the menu.  The pointer grab for the menu should use the timestamp from the event that opens the menu, but it uses the current time.
Component: Drag and Drop → Widget: Gtk
QA Contact: drag-drop → gtk
Some cleanup before I add another caller.
Attachment #593638 - Flags: review?(roc)
Attachment #593638 - Attachment is patch: true
In a subsequent patch I'll add a timestamp to the grab, which will (rightly) increase the likelihood of failure if there have been other events between the event that caused the grab request (button down for menu option) and the actual grab request(s).

This patch ensures that we do the right thing when the grab fails.  The retry code is to deal with popups that are initially zero size.  Zero-sized windows are not viewable and so the grab can't be performed until the window is resized.
Assignee: nobody → karlt
Status: NEW → ASSIGNED
Attachment #593642 - Flags: review?(roc)
Noting that the grab methods here are private clarifies the scope for review, and I noticed that the neighbouring "Native" methods were still virtual from the old CommonWidget base class.
Attachment #593661 - Flags: review?(roc)
Duplicate of this bug: 724688
Depends on: 724966
Depends on: 724967
Blocks: 725047
Depends on: 750061
Depends on: 736811
This ended up exposing a nasty little bug in Unity :)

https://launchpad.net/bugs/1010466
Depends on: 787943
You need to log in before you can comment on or make changes to this bug.