Closed Bug 1170783 Opened 9 years ago Closed 9 years ago

Restoring nsWindow toplevels doesn't work on GTK3, causing test hangs

Categories

(Core :: Widget: Gtk, defect)

Unspecified
Linux
defect
Not set
normal

Tracking

()

RESOLVED DUPLICATE of bug 1170342

People

(Reporter: acomminos, Assigned: acomminos)

References

Details

Attachments

(1 file)

The mochitest browser/base/content/test/general/browser_minimize.js hangs on GTK3 builds when waiting for the window to be restored.
Using present instead of deiconify might be a potential solution; deiconification isn't guaranteed by the WM.

Thoughts, Karl?
Attachment #8614345 - Flags: feedback?(karlt)
This doesn't appear to be an issue with the behaviour of deiconify on GTK3 after a window-state-event notifies us that the window is iconified (at least on Ubuntu 12.04 with Unity 2D, the try server WM). This short program (correctly) endlessly iconifies and deiconifies on test machines.

> #include <gtk/gtk.h>
> #include <gdk/gdk.h>
> gboolean window_state_cb(GtkWidget* widget, GdkEvent* event, gpointer data) {
>   if (!(event->window_state.changed_mask & GDK_WINDOW_STATE_ICONIFIED))
>     return FALSE;
>   if (event->window_state.new_window_state & GDK_WINDOW_STATE_ICONIFIED) {
>     printf("iconified, now deiconifying...\n");
>     gtk_window_deiconify(GTK_WINDOW(widget));
>   } else {
>     printf("deiconified, now iconifying...\n");
>     gtk_window_iconify(GTK_WINDOW(widget));
>   }
>   return FALSE;
> }
> int main(int argc, char* argv[]) {
>   gtk_init(&argc, &argv);
>   GtkWidget* window = gtk_window_new(GTK_WINDOW_TOPLEVEL);
>   gtk_window_present(GTK_WINDOW(window));
>   g_signal_connect(G_OBJECT(window), "window-state-event", G_CALLBACK(window_state_cb), NULL);
>   gtk_window_iconify(GTK_WINDOW(window));
>   gtk_main();
>   return 0;
> }
Status: NEW → ASSIGNED
Comment on attachment 8614345 [details] [diff] [review]
Present instead of deiconify on GTK.

I'm not keen on using present to de-iconify because present will request focus
and that is not necessarily the intention of SetSizeMode().

The test actually seems confused about this because it seems to assume that
the window will receive focus after window.restore().  I don't know that
restore() requests focus.

Do you know whether the window is still not restored, or just not active?

Does your test program fail to restore, if modified to not wait for
window-state-event?

The reason the test waits for focus is because it can't wait for the correct
windowState because the windowState is not giving the true reflection of the
current state.  It would be nice to fix that.  That might be not updating
mSizeState in SetSizeMode() but only in OnWindowStateEvent(), and override
SizeMode() to return mSizeState.  I don't know what might be depending on the
current behavior though.

If this is not causing a problem in real usage, then I'd disable the test or
part of the test for now and leave the bug open.  If the tests can be
annotated with their current state, or disabled where that is not possible,
then we're more likely to notice regressions in tests that are currently
passing.
Attachment #8614345 - Flags: feedback?(karlt) → feedback-
You're right; this is a focus issue upon debugging it. In which case, it's likely related to bug 1170783, and the fact that using present worked around it is probably a fluke.
Depends on: 1170342
Marking as dupe of 1170342, focus seems to be the issue here.
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
No longer blocks: ship-gtk3
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: