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 704819 - Freeze while maximizing window with GTK+ > 3.9.0 and wxWidgets
Freeze while maximizing window with GTK+ > 3.9.0 and wxWidgets
Status: RESOLVED NOTGNOME
Product: gtk+
Classification: Platform
Component: Backend: Wayland
3.9.x
Other Linux
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2013-07-24 15:54 UTC by Thibaud Hulin
Modified: 2014-01-09 15:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Screenshot after maximizing window (282.40 KB, image/png)
2013-07-24 15:54 UTC, Thibaud Hulin
Details
Screenshot before maximizing window (183.94 KB, image/png)
2013-07-25 14:11 UTC, Thibaud Hulin
Details

Description Thibaud Hulin 2013-07-24 15:54:42 UTC
Created attachment 250052 [details]
Screenshot after maximizing window

## What happens:
When I open a window coming from wxWidgets minimal sample and maximize, the window disappears and then I can't select my wlterm.

I installed GTK+ 3.9.0 in another prefix, and I could maximize or resize the window.

I noticed that shaped sample has not this problem.

I placed some break points to see what happens:
gdk_wayland_window_maximize
on_frame_clock_before_paint
gdk_wayland_window_process_updates_recurse
gdk_wayland_window_map
gdk_wayland_window_ensure_cairo_surface
gdk_window_impl_wayland_begin_paint_region
gdk_wayland_window_ensure_cairo_surface
on_frame_clock_after_paint
#Window is moved on top-left corner
shell_surface_handle_configure
gdk_wayland_window_configure
gdk_wayland_window_update_size
buffer_release_callback
frame_callback
on_frame_clock_before_paint
gdk_wayland_window_process_updates_recurse
gdk_wayland_window_map
gdk_wayland_window_ensure_cairo_surface
gdk_wayland_create_cairo_surface
_create_shm_pool
gdk_window_impl_wayland_begin_paint_region
gdk_wayland_window_ensure_cairo_surface
on_frame_clock_after_paint
#Window disappears
frame_callback
on_frame_clock_before_paint


## My configuration :
* OpenSuse 12.3
* GTK+ 3.9.9 and 3.9.0
* Wayland/Weston 1.1.90

## Steps to reproduce:
1. Install Wayland and GTK+
2. Install wxWidgets (http://trac.wxwidgets.org/ticket/15351)
3. Launch minimal sample and maximize
Comment 1 Rob Bradford 2013-07-25 12:18:07 UTC
Can you create a test case that triggers this without using wxWidgets?
Comment 2 Thibaud Hulin 2013-07-25 14:11:01 UTC
Created attachment 250121 [details]
Screenshot before maximizing window

I fear it's too difficult for me, I don't see how I could reproduce it. However the GTK+ window test in testsuite/ fails on this assertion:
"ERROR:window.c:89:test_default_size: assertion failed (gtk_widget_get_allocated_width (box) == 300): (292 == 300)"

Also, I tried to get more infos and some other wxWidgets samples works, but they define their size before they call GTK ; and I noticed that the window doesn't freeze: it reacts to events(I still can close the window if I know where is the button), but the window isn't drawn. Finally, I add a screenshot of the window before it disappears which seems odd.
Comment 3 manuel.BACHMANN@eurogiciel.fr 2013-08-29 15:21:17 UTC
Bug is proper to wxWidgets, and not reproducible with GTK+ itself.

For further insight, please see :

http://trac.wxwidgets.org/ticket/15455