Bug 210056 – [GTK] Several problems with new GTK select elements

• Component: WebKitGTK
• Status: RESOLVED MOVED

[Michael Catanzaro]

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

[Michael Catanzaro]

(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.

[Michael Catanzaro]

This commit introduced other regressions too. I'll ask about it:

7f12dc2b66bba15b2e1c0ca077fa4ae58962ec0f is the first bad commit
commit 7f12dc2b66bba15b2e1c0ca077fa4ae58962ec0f
Author: Jonas Ådahl <[e-mail]>
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(+)

[Michael Catanzaro]

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?

[Michael Catanzaro]

BTW: this bug makes it *really* hard to close bug reports. :P