I'm attaching a couple screenshots to demonstrate problems with the HTML select elements (GtkComboBox). They broke in Tech Preview within the past couple of days. (Tech Preview means 2.28.0 and latest gtk-3-24 branch. The regression will be affecting stable users very shortly as distros update GTK.) Problems: * Width is too small * Height is too small; only shows two or three possible choices * No indication that the view can be scrolled until the area above the scrollbar is hovered
(In reply to Michael Catanzaro from comment #0) > I'm attaching a couple screenshots to demonstrate problems with the HTML > select elements (GtkComboBox). Ugh, foiled by gnome-screenshot... the combo boxes are separate Wayland surfaces and so they don't appear in any of my screenshots. Suffice to say that HTML select elements are quite broken.
This commit introduced other regressions too. I'll ask about it: 7f12dc2b66bba15b2e1c0ca077fa4ae58962ec0f is the first bad commit commit 7f12dc2b66bba15b2e1c0ca077fa4ae58962ec0f Author: Jonas Ådahl <jadahl@gmail.com> Date: Thu Apr 2 16:36:44 2020 +0200 wayland: Postpone window resize requests until configured An application may want to set a fallback size of a window while still mapping maximized. This is done by calling gtk_window_resize() before gtk_window_maximize() and before gtk_window_show(). When the window is mapped, it should have a maximized size, and if it eventually is unmaximized, it should fall back to the size from the earlier gtk_window_resize() call. What happens before this commit is that the initial window size ends up respecting the first gtk_window_resize() dimensions, and not the window dimension configured by the Wayland display server (i.e. maximized dimensions). Fix this by postponing any configure events until we received our configuration from the display server. If we got one with a fixed size (e.g. we're maximized, tiled etc), we use that, otherwise we look at the one that was previously configured by gtk which corresponds to the "preferred" size when not being maximized. This fixes Firefox being started in a maximized state when using the Wayland backend. Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/2538 gdk/wayland/gdkwindow-wayland.c | 18 ++++++++++++++++++ 1 file changed, 18 insertions(+)
Moved to https://gitlab.gnome.org/GNOME/gtk/-/issues/2583. Let's see how it goes there. BTW this seems to affect trunk as well, which is surprising because I thought the select elements would have been rendered using foreign drawing. Are we displaying them from the UI process?
BTW: this bug makes it *really* hard to close bug reports. :P