GNOME Bugzilla – Bug 333470
ComboBoxText and popup menu widgets should ignore minor drags when clicking and releasing
Last modified: 2018-05-02 14:17:32 UTC
It seems there are two ways of selecting an entry in a combo box. Either click and release, choose item and then click and release again. Or click, choose item and then release. I always use the former method. The problem is I often am a bit sloppy in that I don't hold the pointer perfectly still while clicking the first time. This may result in me accidentally clicking, then moving the pointer one pixel before the button is released. This is then interpreted as a selection of the currently chosen item according to the latter method I mentioned above. The result for me, the user, is that I see the combo box meny opening and then closing it self immediately and I don't know what happened because I expected the menu to stay open so that I could choose an item with a second mouse click. This is an issue I've stumbled upon many times and only now do I realize that this is what happens. Before I realized this, I thought that it was either a bug or that I accidentally clicked twice or something. This seems to only occur with combo boxes that have few items so that they pop up very quickly. A possible fix would be to introduce a threshold of, say a few pixels of movement that is required for it to be interpreted as the second method of selection, or using a similar threshold in time. Or, maybe this is a stupid idea and I'm the only one experiencing this problem. I don't know, I just thought anyone might be interested in knowing this. Other information:
I'm expriencing the problem too. When I both click and move the mouse the combo pops down immediately. This is very boring.
I'm seeing this even with GTK3, and it's been bothering me for years. It makes comboboxes very difficult to use for anyone using a stylus or touchscreen or anyone with motor disabilities (ie: an unsteady hand). According to my testing, this issue does not occur if you hold the mouse perfectly still when clicking, but will occur if you move it by a pixel or more before releasing the button (which happens frequently when clicking). In addition to the suggestion above, another possible solution would be to add some sort of timer that waits 250ms or something before accepting further events (it is unlikely that users can read the contents of the combobox popup and make a decision within a split second). Bug #330672 might also be related (or not).
*** Bug 680915 has been marked as a duplicate of this bug. ***
Still happens with 3.4, and also affects popup menus (aka right-click/contextual menus). If I release my right mouse button within a split second, you can be pretty sure it was because I just wanted to show the menu, and that I did not have time to make a choice yet. This also makes it completely unusable for stylus/tablet/touch users, so perhaps Cosimo might be interested.
Still happens in 3.12, and is even worse: A GtkCombobox is *completely unusable* on touchscreens! So, please fix this bug. **Details:** 1. Touchscreens often send MotionNotify-events, even if you don't move, e.g. a click on a touchscreen often results in: ButtonPress with some coordinate, MotionNotify with *same* coordinate, ButtonRelease with same coordinate. But it seems that GTK+ closes the combobox as soon as it sees a MotionNotify event, even if it has exactly the same coordinates as the ButtonPress. This is BAD. 2. There are usually two ways to select something from a combobox: 1. Click -> open popup, Click -> select This does not work on touchscreens (see 1.) 2. Press + move + release over selected item. This also doesn't work on touchscreens; it worked on GTK+2, but on GTK+3, moving after the press tries to *scroll* the contents of the popup instead of selecting an item. This seems to be a nice idea, but then method 1 must work. So, both *DO NOT WORK* on touchscreens, so comboboxes are completely unusable on touchscreens. **Fix:** - ButtonPress + MotionNotify + ButtonRelease should only close the combobox-popup when the MotionNotify-position differs from the ButtonPress-position by more than a few pixels. Ideally: make this threshold configurable.
3.12 is long out of its lifecycle. Please try with 3.18 or 3.20. And we are using touch events with touchscreens.
Personally I'm blocked from retesting this at the moment because of https://bugzilla.redhat.com/show_bug.cgi?id=1349686
I have now tested it with 3.12, 3.14 (of Debian Jessie) and now also with 3.18.9, 3.20.6 and 3.21.3. The problem exist in all versions. I've attached a patch which solves the problem: It only closes the popup again, if the pointer was moved 20 pixels or more before the release. The threshold of 20 pixels worked well in a test on a Lenovo X200T (with pen/digitizer, no finger-touchscreen; 10 pixel weren't enough). But I don't know if larger values are necessary for high-resolution displays; so this patch could be improved by making the threshold configurable or dependent on the display-dpi. I'll test my patch again on a capacitive Iiyama touchscreen and report the results here.
Created attachment 330376 [details] [review] patch to fix the problem
Update: The patch did not work on the Iiyama touchscreen; I've now attached an extended patch, which also works on the Iiyama touchscreen. The only not-so-beautiful effect, is, that when I touch the combobox on the touchscreen, the (blue) select-bar on the current entry shows shortly and disappears again, so it "blinks" once. It would probably be nicer if the select-bar would stay. But I don't know how to fix this aesthetic issue. Details: I've analyzed, which GTK+ events cause the behavior. The results are: 1. Touchscreens send more motion-notify-events -- even if the position has not changed. My first patch fixed this for GTK+. 2. The Iiyama capacitive touchscreen sends the same events, but something is different, so that in ine gtk_menu_motion_notify, activate_time is set to 0. My updated fix additionally solves this. 3. gtk_menu_enter_notify() and gtk_menu_leave_notify() check for "GDK_SOURCE_TOUCHSCREEN". I don't know what this really means, but I noticed that the check for "GDK_SOURCE_TOUCHSCREEN" was *always* false, even with the X200T pen and on the Iiyama touchscreen.
Created attachment 330893 [details] [review] updated patch, now also works on my Iiyama touchscreen
Review of attachment 330893 [details] [review]: I wonder if commit 40ab7e1c958733125cb0f470fa77e5fa74985629 in GTK+ 4 changes anything regarding this; it affects some of the same code. No comment on the sense, just coding style. Firstly, please submitted a git-formatted patch, so that it can be merged without so much hassle if accepted. ::: gtk+-3.20.6/gtk/gtkmenu.c @@ +104,2 @@ #include <string.h> +#include <math.h> // for fabs() We're still using C89 comments only as far as I can see. @@ +1726,3 @@ + (current_event->type == GDK_BUTTON_RELEASE)) + { + priv->press_x = ((GdkEventButton*)current_event)->x; I doubt it matters, but afaics we tend to cast (Like *)this, i.e. with a space. @@ +3455,3 @@ + */ + gdouble moved; + moved = fabs(event->x - menu->priv->press_x) + We put spaces between function names and argument lists @@ +3875,3 @@ + * (Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=703069) + */ + //menu_shell->priv->activate_time = 0; Don't leave dead code in the file. If this is to be removed, then so should everything around it, if it achieves nothing. You could replace it all with a comment explaining why something people might expect to happen is not happening. ::: gtk+-3.20.6/gtk/gtkmenuprivate.h @@ +54,3 @@ gint position_y; + /* store pointer-position at popup and a motion-threshold, so that I really doubt you need to repeat this comment in every single place that's involved. @@ +56,3 @@ + /* store pointer-position at popup and a motion-threshold, so that + * press + small move + release does not close the menu/combobox again. + * (Fixes: https://bugzilla.gnome.org/show_bug.cgi?id=703069) We don't dump bug URLs in code when bugs are fixed, only when documenting the reasons for kludges that we hope to remove. Otherwise, the whole thing would be a complete mess.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/258.