After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 791081 - gtk_widget_realize() throws In pixman_region32_init_rect: Invalid rectangle passed
gtk_widget_realize() throws In pixman_region32_init_rect: Invalid rectangle p...
Status: RESOLVED OBSOLETE
Product: gtk+
Classification: Platform
Component: Widget: Other
3.22.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2017-12-01 13:00 UTC by Martin Stransky
Modified: 2018-05-02 19:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Simple testcase (533 bytes, text/plain)
2017-12-01 13:00 UTC, Martin Stransky
  Details
[PATCH] GtkWindow: Preserve window allocation with CSD (3.21 KB, patch)
2017-12-06 13:54 UTC, Olivier Fourdan
none Details | Review

Description Martin Stransky 2017-12-01 13:00:12 UTC
Created attachment 364749 [details]
Simple testcase

Seting custom titlebar throws an error when window size is smaller than CSD decoration size - Gtk creates opaque surface with negative size then:

This simply sequence causes that:

gtk_window_resize(GTK_WINDOW(window), 1, 1);
gtk_widget_realize(window);
gdk_flush();

gtk_widget_unrealize(window);
gtk_window_set_titlebar(GTK_WINDOW(window), gtk_fixed_new());
gtk_widget_realize(window);

That affects Firefox when the main window has a minimal widget size and the main window is configured before it's shown.
Comment 1 Olivier Fourdan 2017-12-05 15:42:58 UTC
I think we hit a corner case here.

Basically, when the gtk_window_resize(GTK_WINDOW(window), 1, 1); is issue, we don't have CSD enabled, so 1x1 is a valid size.

Then the windos widget is unrealized, gtk_window_set_titlebar() is invoked and enables CSD, which means that the decorations will be taken from the window size.

So eventually, when we realize the window with its requested size of 1x1, the client side decorations are substracted which leads to negative sizes.
Comment 2 Martin Stransky 2017-12-06 07:21:14 UTC
Yes, that's correct. It applies to any widget size smaller than CSD shadows size, which is ~ 50x50 pixels for me at Fedora 26.
Comment 3 Olivier Fourdan 2017-12-06 07:26:24 UTC
By corner case, I meant there are mechanisms in place in gtk to avoid this, but by creating the widget w/out CSD, resizing it to 1x1, realizing it, unrealizing it, adding a title bar which enables CSD, realizing it again and eventually showing the widget, all that sequence defeats the mechanisms in place :)
Comment 4 Olivier Fourdan 2017-12-06 13:54:30 UTC
Created attachment 365108 [details] [review]
[PATCH] GtkWindow: Preserve window allocation with CSD

FWIW, this seems to avoid the issue.
Comment 5 Matthias Clasen 2017-12-08 01:51:19 UTC
I'm not really in favor of adding code to save the skin of people who gtk_window_resize (w, 1, 1) - at some point, we have to rely on common sense to prevail...
Comment 6 Martin Stransky 2017-12-08 07:35:51 UTC
(In reply to Matthias Clasen from comment #5)
> I'm not really in favor of adding code to save the skin of people who
> gtk_window_resize (w, 1, 1) - at some point, we have to rely on common sense
> to prevail...

It's not the (1,1) size only but any size smaller than CSD shadow size. Which is 50 x 50 pixels on my system (Fedora 27).
Comment 7 Martin Stransky 2017-12-08 07:37:49 UTC
Anyway, Firefox can live with this bug as we have a workaround for it - there are definitely more important ones.
Comment 8 Olivier Fourdan 2017-12-08 07:38:38 UTC
(In reply to Martin Stransky from comment #6)
> (In reply to Matthias Clasen from comment #5)
> > I'm not really in favor of adding code to save the skin of people who
> > gtk_window_resize (w, 1, 1) - at some point, we have to rely on common sense
> > to prevail...
> 
> It's not the (1,1) size only but any size smaller than CSD shadow size.
> Which is 50 x 50 pixels on my system (Fedora 27).

Yes, but you'll notice the resize ther eis usless and doesn;t give you the expected size of 1x1 anyway.

The following would work, i.e. avoid the negative window size *and* get you the requested size:

    gtk_init(&argc, &argv);

    window = gtk_window_new(GTK_WINDOW_TOPLEVEL);

    gtk_widget_realize(window);
    gdk_flush();

    gtk_widget_unrealize(window);
    gtk_window_set_titlebar(GTK_WINDOW(window), gtk_fixed_new());
    gtk_window_resize(GTK_WINDOW(window), 1, 1);
    gtk_widget_realize(window);

    gtk_widget_show_all(window);
    gtk_main();
Comment 9 Eric Williams 2017-12-11 19:25:44 UTC
I know this isn't a major bug, but FWIW we see this in Eclipse SWT as well under certain conditions.
Comment 10 Olivier Fourdan 2017-12-12 08:06:27 UTC
Hi, “under certain conditions” is key here, because when using the appropriate GtkWindow API, this cannot happen, so it's a bit difficult for me to help without knowing the context on what SWT and Eclipse are doing.

Besides, as I said in comment 8, when using the right API in the right order, not only the issue doesn't occur but the desired window size (the one given in gtk_window_resize) can be achieved as well.
Comment 11 Eric Williams 2017-12-12 20:12:21 UTC
(In reply to Olivier Fourdan from comment #10)
> Hi, “under certain conditions” is key here, because when using the
> appropriate GtkWindow API, this cannot happen, so it's a bit difficult for
> me to help without knowing the context on what SWT and Eclipse are doing.
> 
> Besides, as I said in comment 8, when using the right API in the right
> order, not only the issue doesn't occur but the desired window size (the one
> given in gtk_window_resize) can be achieved as well.

Thanks for the explanation, I haven't looked at the SWT bug in awhile to know exactly what conditions it's happening under. Once I get to it I'll remember to come back and look at this bug. :)
Comment 12 GNOME Infrastructure Team 2018-05-02 19:31:04 UTC
-- 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/983.