GNOME Bugzilla – Bug 794036
Wayland: ComboBox popup menu not shown when item at high index is active
Last modified: 2018-03-30 08:50:10 UTC
Created attachment 369259 [details] MWE for testing the broken popup in the Gtk::ComboBox The Gtk::ComboBox functionality seems to be broken when there are too many items to choose from. The MWE in the attachment demonstrates the problem (top of the file shows compilation method). The program creates a window with a Gtk::ComboBoxText with 150 items. Initially, item #0 is selected. Clicking on the combo the first time works as expected. A drop down appears and all items can be selected. When the selected item is in the first number of items (item #0 to item #37) and the combo is clicked a second time, it is still working properly. When one of the items lower in the list is selected (#38 to the end), clicking the combo does not show the drop down and selecting another value is impossible. When the combo box has focus (but has not been clicked), it is possible to select other values with the arrows. After pressing the up-arrow many times to select one of the top values, the drop down is working again. Problem occurs in a fully updated Fedora 27 machine in the Gnome shell. Gnome version 3.26.2, gtk3 version 3.22.26, kernel version 4.15.6-300.fc27.x86_64, and gcc version 7.3.1 20180130 (Red Hat 7.3.1-2). Note, the example demonstrates the problem with Gtk::ComboBoxText for simplicity, but the problem also occurs in Gtk::ComboBox widgets.
I've run your test case on my Ubuntu 17.10 system, with two versions of gtk+. 1. gtk+-3.0 3.22.25 as provided by Ubuntu 2. gtk+-3.0 3.22.28 from the git repository, gtk-3-22 branch With both these versions of gtk+, your test program works as expected. The drop down list is always shown, regardless of which item has been selected. (Well, I haven't tested all 150 items, but I've tested items with both low and high (>100) numbers.)
Test case also runs well on a virtual machine with a fully updated Fedora 27 (this VM is running on a different system). The main difference between the original setup and the virtual machine is that the VM runs with Gnome 3 in the 'fallback mode' with a lower resolution.
Created attachment 369384 [details] C test case I have translated your test case to C/gtk+. Can you check if it fails in the same way as your C++/gtkmm test case? If it does, this bug report should be transferred to gtk+. I don't think the bug is in gtkmm. Perhaps it's not in gtk+ either, but hopefully a gtk+ developer can understand which module is to be blamed.
(In reply to sawims from comment #0) > Problem occurs in a fully updated Fedora 27 machine in the Gnome shell. > Gnome version 3.26.2, gtk3 version 3.22.26, kernel version > 4.15.6-300.fc27.x86_64, and gcc version 7.3.1 20180130 (Red Hat 7.3.1-2). And what theme are you using? Chiefly, I'd like to know whether it, or your user CSS, or anything else applies the style property > -GtkComboBox-appears-as-list: true since that changes CBs to an alternative mode that has sadly been neglected and accumulated a high number of bugs (some of which I've been able to fix recently).
(In reply to Kjell Ahlstedt from comment #3) > Created attachment 369384 [details] > C test case > > I have translated your test case to C/gtk+. Can you check if it fails in the > same way as your C++/gtkmm test case? If it does, this bug report should be > transferred to gtk+. I don't think the bug is in gtkmm. Perhaps it's not in > gtk+ > either, but hopefully a gtk+ developer can understand which module is to be > blamed. Thanks. Your C/gtk+ test case has the same problem as the C++/gtkmm version, so I guess you are right that the problem doesn't lie in gtkmm.
(In reply to Daniel Boles from comment #4) > And what theme are you using? Chiefly, I'd like to know whether it, or your > user CSS, or anything else applies the style property The system is still in its default Fedora 27 configuration. The theme used by default is "Adwaita (standard)". I've never made any user specific changes to the theme. Is there an easy way to find the setting of '-GtkComboBox-appears-as-list:' on the system?
I can't see one immediately. Sadly, the Inspector doesn't visualise style properties, afaics (and I guess there's no point making it, since they're all gone in GTK+ 4). I guess you could try overridding the property to false and seeing if that changes anything. But sounds from your system like it won't be true anyway.
https://gitlab.gnome.org/GNOME/gtk/issues/94 may be a dupe of this. Are you both using Wayland?
Yes, running Wayland as installed by Fedora 27. The two tests from https://gitlab.gnome.org/GNOME/gtk/issues/94 show the same results on my system. Running the gtk+ or the gtkmm MWE's with the XWayland instead of Wayland (e.g.: GDK_BACKEND=x11 ./test_combo) makes the program run as expected.
Kjell, were you on Wayland or X11? I guess the latter? sawims, at what index does the menu stop popping up? Does that index correlate with e.g. the height of your screen? I guess we could do with some debug prints to check whether the menu's window ends up at bizarre coordinates or suchlike.
Yes, I'm on X11.
Bug 781044 seems related and possibly ultimately a duplicate. Excerpts: (In reply to Milan Crha from comment #2) > One important detail, it happens only if the combo content is taller than > screen height. I had been able to reproduce it in the Calendar view, where > the similar combo at the top contains all the preconfigured categories, plus > some other items, which makes it tall enough to strike. I'm moving this to > gtk+, because I believe the issue is there. (In reply to Milan Crha from comment #3) > Created attachment 354834 [details] > test-combo.c > > This is a little test program, which doesn't exhibit what on the screenshot > is, but it looks as close to me that I believe fixing it will help to fix > the issue "in evolution" as well. > > When compiled & run (see the first line of the file), each of 5 combo boxes > has its item selected. The first three show the popup as expected, the last > two do not show it, even though it is expanded "somewhere", because I can > use arrows on the keyboard to change selection, the same as the combo itself > has visual indication that it's pressed-down. I would be interested in feedback on whether this sounds the same - i.e. whether * the problems you saw are indeed related to the height of the menu vs. the position of the active item therein * pressing keys does result in stuff happening, indicating that the menu is open *somewhere*, even if that's nowhere we can ever see.
(In reply to Daniel Boles from comment #12) > I would be interested in feedback on whether this sounds the same - i.e. > whether > * the problems you saw are indeed related to the height of the menu vs. the > position of the active item therein > * pressing keys does result in stuff happening, indicating that the menu is > open *somewhere*, even if that's nowhere we can ever see. * Yes, the problems sound the same. * Yes, when the combo box is selected (not pressed), it is possible to select other items. While testing the program by Milan Crha I noticed that I didn't get the same results all the time. A bit more investigations showed that the position of the ComboBox on the screen is important. Going back to Kjell's test program (comment #3) which has a nice small window I did some more tests. I started this program and made the window as small as possible (somehow there is more room allocated than the minimal amount needed in Wayland). When the window is at the bottom of my 1920x1080 monitor the combo box keeps on working as expected until "Option 56" is selected. If the window is at the top of the screen the combo box keeps on working until "Option 25" is selected. The difference seems to (unsurprisingly) correspond to the number of items that is shown in the popup (32 items). I'll post a screenshot of this test.
Created attachment 370158 [details] Behaviour of the ComboBox at different positions of the screen Screenshot of running the test program with the combo box placed at different positions on the screen. At the left is a combobox showing the first 32 options. At the right are five instances of the program with the first option selected where the combobox is not working anymore. E.g., the window with Option 25 select will not show the list op options when clicked. When changing the selection to Option 24 the list does show up correctly. Note how the distance between two windows and the selected option corresponds to the distance in the option list.
GitLab just got a very illuminating comment from Olivier, which would be impractical to paste here, and it depends on attachments there too... so let's go the opposite way: reopen the GitLab one and keep discussion there. https://gitlab.gnome.org/GNOME/gtk/issues/94#note_92003