GNOME Bugzilla – Bug 520165
typeahead find (interactive search) only accepts one character in 2.12.8
Last modified: 2008-08-22 00:32:22 UTC
Please describe the problem: In GTK+ 2.12.8, using the interactive search on a GtkTreeView no longer works correctly; it'll only accept a single character after which, the input field is unresponsive even though the cursor continues to flash. Steps to reproduce: Using gtk-demo, open the "Tree View->List Store" demo and start typing to activate the interactive search. Actual results: Expected results: Does this happen every time? Other information:
A slight variant: Type <ctl>f to pop-up the search window; At this point: keyboard entry to the search window seems to be ignored and eventually the search window "times out" and is dismissed. (The cursor is shown within the GtkEntry). Additional information: a. This problem does not occur in my Linux environment (Fedora 8); b. Falling back *just* the libgdk dll to the 2.12.6 version causes the search to work AOK again. (I've no idea if one is really allowed to fall back just the libgdk dll).
I'm experiencing this bug in Pidgin 2.4.0 on Windows Vista. Related Pidgin bug: http://developer.pidgin.im/ticket/4966
We're tracking this as Wireshark bug #2325: http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=2325
Daniel prodded me in irc just now, so I'll do this today. I didn't have a Win32 setup to test on when I was in Berlin so I just put this off last week, sorry about that.
*** Bug 526805 has been marked as a duplicate of this bug. ***
*** Bug 535912 has been marked as a duplicate of this bug. ***
*** Bug 535027 has been marked as a duplicate of this bug. ***
I've done some further analysis and found the cause. One of the parts of revision 19545, was to suppress keypresses for windows that are "modally blocked" (gdk/win32/gdkevents-win32.c:1771). This is where the subsequent keypresses are being eaten. The typeahead window is the current modal window, but (clearly) it isn't the toplevel window for the window receiving the keypresses (which is the window containing the GtkTreeView). I'm not sure what the correct solution is - should the keypresses actually be directly received by the typeahead window? (why are they not?) Should the modal blocking code somehow be able to tell that these keypresses should through even though it isn't the modal window?
Created attachment 112755 [details] [review] Fix This is kind of a hacky solution, and I'm not sure yet if there's a better way to do it. I need to talk to Kris, because I don't really understand yet what TreeView is doing here. It kind of seems like the key strokes are being received by something else, and I'm not sure if it's the TreeView or what. It's not the modal_current. It seems that TreeView is the only thing using GDK_WINDOW_TYPE_HINT_UTILITY, so theoretically this should not affect anything else. :) Doesn't the file selector have a similar search box? Do you happen to know if it is affected by this issue as well?
Yes, it also happens for the file selector. See this bug #526805
(In reply to comment #2) > I'm experiencing this bug in Pidgin 2.4.0 on Windows Vista. Related Pidgin bug: > http://developer.pidgin.im/ticket/4966 > Indeed, this bug is still occurring on Pidgin 2.4.3. What's holding up patching trunk?
There's not a good solution yet. The patch I posted above is not good. I need to dig into GtkTreeView code I think, and I'm not looking forward to that. :) The alternative is to back out the patch that caused this problem, but I don't want to do that either because the problems that were solved in that patch were much bigger and more important than this one.
*** Bug 524169 has been marked as a duplicate of this bug. ***
Created attachment 115635 [details] [review] A different fix This makes much more sense.
(In reply to comment #14) > Created an attachment (id=115635) [edit] > A different fix > > This makes much more sense. This patch certainly fixes this bug. I've been using it for a few days and haven't noticed any ill effects (I don't use very much modal stuff though).
Are there any issues with the patch? If not, can we get it committed soon?
2008-08-21 Cody Russell <bratsche@gnome.org> * gdk/win32/gdkevents-win32.c (doesnt_want_key): Remove the checks to see if the window is modally blocked. This doesn't get us anything, and it confuses the search window in GtkTreeView (and potentially other utility windows in other apps). (#520165)
Committed to gtk-2-12 branch as well. Thanks for reminding me about this one, I had forgotten that I didn't commit it yet.