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

Status: RESOLVED FIXED

(Core :: Widget: Gtk, defect)

Description

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

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.

Comment 1

[Ian Nartowicz]

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?

Comment 2

[Karl Tomlinson (:karlt)]

Can the popup be closed before initiating the drag?

Comment 3

[Karl Tomlinson (:karlt)]

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.

Comment 4

[Karl Tomlinson (:karlt)]

Attachment: remove unused GdkWindow parameter to check_for_rollup

Some cleanup before I add another caller.

Comment 5

[Karl Tomlinson (:karlt)]

Attachment: part 2: don't keep trying pointer grab when failing due to another application's grab

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.

Comment 6

[Karl Tomlinson (:karlt)]

Attachment: privatize and devirtualize a few nsWindow methods

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.

Comment 7

[Karl Tomlinson (:karlt)]

Attachment: part 4: use a timestamp when grabbing the pointer and generate timestamps for drags in the same way

Comment 8

[Karl Tomlinson (:karlt)]

https://hg.mozilla.org/integration/mozilla-inbound/rev/34e3dad7a39d
https://hg.mozilla.org/integration/mozilla-inbound/rev/31d649d2db25
https://hg.mozilla.org/integration/mozilla-inbound/rev/ca19aff687a1
https://hg.mozilla.org/integration/mozilla-inbound/rev/050334f9128c

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/34e3dad7a39d
https://hg.mozilla.org/mozilla-central/rev/31d649d2db25
https://hg.mozilla.org/mozilla-central/rev/ca19aff687a1
https://hg.mozilla.org/mozilla-central/rev/050334f9128c

Comment 11

[Chris Coulson]

This ended up exposing a nasty little bug in Unity :)

https://launchpad.net/bugs/1010466