GNOME Bugzilla – Bug 92085
tooltip is not removed when dragging menu item from panel to desktop
Last modified: 2014-03-24 02:54:43 UTC
The original bug #91884. To Recreate ============= Select and hold mouse pointer over "Applications:Help" unil tooltip appears Now click and drag Help to desktop to create a new desktop launcher The result is that the Help tooltip remains until you click on another menu. How to get rid of it -------------------- move the mouse over a panel object (launcher or an applet) the tooltip disappears. A single GtkTooltips object handles both the menuitems and objects on the panel. This bug does not occur when you drag an item from the menu to the panel, and I guess for the same reason above. I have attached a workaround patch in the panel code where 1)gtk_tooltips_disable on starting the drag 2)gtk_tooltips_enable on dropping the item. okay, Mark has not accepted/seen it yet ;-) Should gtk not provide the support for popping down the tooltips when the dnd happens instead of this workaround ?
(This is closely related to 90400 - basically DND with menus just works by coincidence and really needs some official support in GTK+) OK, debugged the "why" of this bug consider the situation with three windows: +---------------+ +--+ | +----+ | |C | | | B | A | +--- | +----+ | +---------------+ If we XGrabPointer (win = A, owner_events = TRUE); move pointer into window B XGrabPointer (win = C, owner_events = FALSE); Then we'll get the events: EnterNotify for A (detail = NotifyGrab) EnterNotify for A EnterNotify for B LeaveNotify for A (detail = NotifyGrab) EnterNotify for C (detail = NotifyGrab) That is, the second XGrabPointer generates enter-leave between the old and new windows, not between the sprite window and the new window. So, we don't get a LeaveNotify for B - Enter/Leave events for B don't come in pairs, which violates an assumption that we make in GTK+ that they will always be paired.
Move various non-critical bugs onto 2.2.1 milestone.
No real idea about how to fix this other than a long-term plan to make GTK+ only ever grab on toplevel windows and simulate other grab events itself. Maybe gtk_drag_begin could send a synthetic leave event to the source window for the drag.
This is almost certainly also what causes bug 108166.
*** Bug 144560 has been marked as a duplicate of this bug. ***
I cannot replicate that bug anymore. The tooltip now always disappears when I initiate a drag.
This is puzzling indeed. With XGrabPointer (win = A, owner_events = TRUE); move pointer into window B XGrabPointer (win = C, owner_events = FALSE); I get the following events enter notify: window: A mode: Grab detail: Nonlinear enter notify: window: B mode: Normal detail: Nonlinear leave notify: window: A mode: Grab detail: Nonlinear enter notify: window: C mode: Grab detail: Nonlinear but if I do an explicit ungrab: XGrabPointer (win = A, owner_events = TRUE); move pointer into window B XUngrabPointer () XGrabPointer (win = C, owner_events = FALSE); I get enter notify: window: A mode: Grab detail: Nonlinear enter notify: window: B mode: Normal detail: Nonlinear leave notify: window: A mode: Ungrab detail: Nonlinear enter notify: window: B mode: Ungrab detail: Nonlinear leave notify: window: B mode: Grab detail: Nonlinear enter notify: window: C mode: Grab detail: Nonlinear So when the X protocol spec says "The [GrabPointer] request overrides any active pointer grab by this client" it means something else than an implicit ungrab.
right, there is no ungrab, just another grab. and, when using owner-events = TRUE, this means that the mouse effectively 'warps' from A to C without ever even looking at B in the process. That these odd EnterNotify events were delivered while the pointer was grabbed doesn't enter into the picture. Having the server do any differently would require looking at the owner-events differences between the two grabs and synthesizing LeaveNotify events to match whatever EnterNotify events were delivered while the first grab was active. That seems really hard to me. I see three client-side solutions: 1) Stop using owner-events = TRUE. No more mysterious EnterNotify events on B. 2) Recognize EnterNotify events while the pointer is grabbed as 'special' and make plans to synthesize LeaveNotify events as appropriate when the grab is changed to not use owner_events = TRUE 3) Ungrab the pointer before grabbing it again. I fear races and other nasty surprises with this route. 4) Discard (some) Enter/Leave events while the pointer is grabbed. Figuring out which ones seems tricky though.
*** Bug 123323 has been marked as a duplicate of this bug. ***
*** Bug 311935 has been marked as a duplicate of this bug. ***
still there with Gnome 2.11.92 , gtk+ 2.8.3. Raising version. setting gtk+ 2.8.x
closing out ancient bugs