After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 59812 - Problem with first entry of contextual menus
Problem with first entry of contextual menus
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Widget: Other
1.3.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2001-08-31 09:03 UTC by Arnaud Charlet
Modified: 2011-02-04 16:09 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Arnaud Charlet 2001-08-31 09:03:47 UTC
Using Gtk+ 1.3.6, when displaying a contextual menu, the first item
is not selected/highlighted as it should be (wasn't a problem with
Gtk+ 1.2.x). Moving the mouse on the second item and back to the first
avoids the problem.

Arno, for the GtkAda team
Comment 1 Owen Taylor 2002-02-02 21:07:27 UTC
Tracked this one down ... the problem is that the "implicit
grab" for the button press is still in effect when the menu
pops up, and since GTK+ no longer specifies OwnerGrabButtonMask,
this means that the enter/leave events that would otherwise
go to the menu when it pops up under the pointer aren't 
delivered.

You'd expect to get the events then when the grab was overriden
by the menu, but it turns out that the X protocol doesn't
really fully specify what events get sent when a client
overides it's own grab, and the events the sample implementation
sends aren't useful.. the old window will get a LeaveNotify,
but no EnterNotify will be received.

So, we need to hack around the problem in some fashion. One
possibility would be to do do something like gdk_pointer_grab()
on the root window with owner_events = TRUE before popping
up the window. But the problem with that is that even if
a gtk_grab_add() is in effect, events on the root window will
be dropped on the floor rather than delivered to the grab
window with that way gtk_main_do_event() is written.

A variant would be to grab on a mapped, offscreen window,
with user_data pointing to our widget; but then we need
to worry about memory management of this window. Not
impossible, but a little bit of a pain.

A final possiblity, probably simplest, would be query
the pointer location after mapping the window and synthesize
an event if necessary ... you may get two enters in this
case if the menu wasn't popped up from a button press.

Comment 2 Owen Taylor 2002-02-02 21:49:26 UTC
I went ahead and implemented the complicated grab on an offscreen/mapped
window solution.

Sat Feb  2 16:43:31 2002  Owen Taylor  <otaylor@redhat.com>

	* gtk/gtkmenu.c (gtk_menu_popup): To get around the fact
	that we may have a owner_events = FALSE grab in effect
	when we pop up a window, make a temporary grab on a
	different window, then grab on the real window. Fixes
	a problem where if a context menu popped up under the 
	cursor, the first item would be stuck unselected.
	(#59812, reported by Arnaud Charlet.)