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 106520 - No flush after gdk_display_ungrab_keyboard()
No flush after gdk_display_ungrab_keyboard()
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
2.2.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2003-02-19 14:12 UTC by Rajkumar
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: 2.3/2.4



Description Rajkumar 2003-02-19 14:12:49 UTC
Test case:
---------
a) Open a large file (Approx. 10K of lines) in Gedit
b) Open the Find Dialog (Ctrl + f)
c) Enter a junk string that is not present in in file (so that the search
engine scans the entire doc)
d) Hit the "Return Key" and initiate the search. Our keyboard will be
grabbed until the search is complete and you will not be able to use it in
the mean time.

This is common for GtkDialogs which runs a background operation for a key
response and its effect is very severe in certain cases when the call back
for button press pops up an UI like GtkEntry as the user can't use the
keyboard as its grabbed.

On further analysis its found that the X request queue doesn't get flushed
in gtk_button_finish_activate() of gtkbutton.c.

Also pls. refer the discussions at:
http://mail.gnome.org/archives/gtk-devel-list/2003-February/msg00043.html
Comment 1 Owen Taylor 2003-02-19 19:45:48 UTC
I'm thinking that we perhaps should just add XFlush() to
gdk_display_ungrab_keyboard() / gdk_display_ungrab_pointer().

Comment 2 Owen Taylor 2003-04-21 19:12:42 UTC
Mon Apr 21 15:07:29 2003  Owen Taylor  <otaylor@redhat.com>
 
        * gdk/x11/gdkdisplay-x11.c (gdk_display_keyboard/pointer_ungrab):
        Calling XFlush() after ungrabbing, to avoid problems if
        the app subsequently blocks on a long-running operation.
        (#106520, reported by Rajkumar Siva)