Please provide a small standalone compilable test case.

OK, here's a modified helloworld:

---- snip ----
#include <gtk/gtk.h>

GtkWidget *window;
int fullscreen = FALSE;

void hello(GtkWidget *widget, gpointer data)
{
  if (fullscreen) {
    g_print ("unfullscreening\n");
    gtk_window_unfullscreen(GTK_WINDOW(window));
    fullscreen = FALSE;
  }
  else {
    g_print ("fullscreening\n");
    gtk_window_fullscreen(GTK_WINDOW(window));
    fullscreen = TRUE;
  }
}

int main(int argc, char *argv[])
{
  GtkWidget *button;
    
  gtk_init (&argc, &argv);

  window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
  /* comment next line to show that fullscreening otherwise works */
  gtk_window_set_resizable(GTK_WINDOW(window), FALSE);
    
  button = gtk_button_new_with_label ("Hello World");
  g_signal_connect (G_OBJECT (button), "clicked",
		    G_CALLBACK (hello), NULL);
    
  gtk_container_add (GTK_CONTAINER (window), button);
  gtk_widget_show (button);
  gtk_widget_show (window);

  gtk_main ();
    
  return 0;
}
---- snip ----

If you drop it in gtk+/examples/helloworld/, the Makefile there will
be able to compile it. What happens is that if you press the button,
the window does not go to fullscreen because of the call to
gtk_window_set_resizable. Remove that call and it works. This is with
Metacity 2.6.3 and an otherwise standard Gnome desktop.

Quite arguably, the problem is that it *does* fullscreen if
the hint is set before it is mapped.

But in any case, seems to me to entirely be a metacity issue,
either way. GTK+ sends the "fullscreen" message to the window
manager without worrying about whether it is resizable or not.

I believe the intent of the current metacity code is that you can't
fullscreen a not-resizable window. It would be helpful to tell us
about the app so we know what the use-case is and can understand what
changes make sense.

OK. I believe get_window_set_resizable() is supposed to make it
impossible for the user to grab the window edge and resize the window,
but that it should not affect the ability of the program to change its
window size. That's why I think this is a bug.

My application is a game (Monster Masher) which has a fixed size play
field (determined at run time, though). Thus I make the window
unresizable. But I also want to support fullscreen mode so that the
user can toggle a button and have the game take up all of the screen
space. For instance, this is sometimes needed to avoid that the window
is partly covered by the panel.

Currently, I can't do that properly.

Ah, it's not quite that simple; resize and state change requests can
come from all over, e.g. the libwnck library lets you write apps such
as the window list and workspace switcher that do this.

What gtk_window_set_resizable() does is not about the controls
displayed - it imposes constraints such that the window isn't
_allowed_ to be resized by anyone. As a side effect the window manager
removes the resize controls to properly indicate what's allowed.

OK, but don't you agree that it can make sense to allow fullscreen
mode even if you don't allow other resizing mechanisms? Or do you have
other suggestions for what to do?

Currently, I don't turn resizability off, but it is a bit lame to have
the grips when the application cannot meaningfully support them - you
just get a grey border around the gaming field canvas.

Having in the past played some other games where resizing didn't make
sense, having a feature that Olau is requesting seems it would have
been useful.  Would there be a possiblity of allowing an application
to differentiate between not allowing user interaction to resize the
window and not allowing the app itself or user interaction to resize
the window?  I don't have a clue how that would be implemented but I'd
lump libwnck and any other such external programs along with 'user
interaction'. 

I guess a workaround is to have the app make the window resizable,
resize it, and then immediately make it unresizeable again.  Perhaps
throw this inside a while loop that checks to make sure the end window
size is exactly what you expect just to avoid any problems from the
user somehow resizing the window inbetween you making it resizable and
freezing its size again.

*shrug*

I'm afraid the suggestion of making the window unresizable just before
going to fullscreen and then change the resizability back again does
not work. At least if I recall correctly, that was the first thing I
tried. :-)

I think the value needs to be set before the window is shown - and
then it's final. But I might be wrong.

The problem here is really that the non-resizable hints are much more
fundamental, lower-level hints than the EWMH fullscreen hint.  In the
interest of compatibility, the EWMH hints really have to take a back
seat to older, more standard hints.

Since "make me full screen" and "don't resize me no matter what" are
contradictory, a policy decision needs to be made by the window
manager as to which hint is more important.  In this case, it has to
be the non-resizable hint, for backwards compatibility.

The only solution would really be to add an additional EWMH
non-resizable hint to which we could assign more flexible semantics,
including assigning priority to things like _STATE_FULLSCREEN and
_STATE_MAXIMIZED_{VERT|HORIZ}.  It may be worth bringing this up on
wm-spec-list.

Yeah, I think the behavior you're after is reasonable, it just doesn't
seem to be allowed by the current specs.

Because this would require a spec extension, I'm reassigning the component...

*** Bug 116343 has been marked as a duplicate of this bug. ***

Bug 116343 also has some good discussion (it was more specifically about a
window that is already the size of the screen on a second xinerama monitor, but
nevertheless is the same basic idea) as well.

I'm going to retitle the bug to make it easier to find...

I don't think this needs any spec change.  As per the suggestion of both Matthias (bug 327543 comment 5) and Havoc (bug 327543 comment 3), we ignore maximum size constraints when maximizing windows.  Since fullscreening and maximizing are very similar operations, it seems oddly inconsistent to pay attention to max size hints when fullscreening windows and not to pay attention to them when maximizing.  So, I think we should just allow windows to be fullscreened even if it violates size increment or maximum size constraints.  That will automatically fix both this bug and bug 116343/bug 427902.

Does it make any difference that the original bug was raised before you rewrote the constraints code?  This should just be a matter of reversing the order of the priorities of these two constraints.

bugzilla.gnome.org is being replaced by gitlab.gnome.org. We are closing all old bug reports in Bugzilla which have not seen updates for many years.

If you can still reproduce this issue in a currently supported version of GNOME (currently that would be 3.38), then please feel free to report it at https://gitlab.gnome.org/GNOME/metacity/-/issues/

Thank you for reporting this issue and we are sorry it could not be fixed.