There's already a long saga of trying to get this workaround right, 
if you find the right bugzilla comments and cvs logs you could 
reconstruct it.

The current workaround is in stack.c:get_standalone_layer(), 
window_is_fullscreen_size()

I saw the current workaround, and noticed that it was only affected
the stacking order and not geometry.  I used the same function to
simply assign window->fullscreen (which isn't quite right) and my
full-screen apps started working nicely.  Much as the window type of
non-ewmh apps is inferred from various window attributes, I think the
fullscreen attribute could be easily guessed by the initial
application geometry, if it matches the size of the screen, the
application could be placed in fullscreen at startup time.  The fix is
trivial; delete the special case in the stacking mode code and
initialize fullscreen from meta_window_new using similar code.

The current partial kludge seems the worst of both worlds -- an
unmanagable window that can't obscure the panel.

If you look at the cvs logs and find the right diff, you'll see that 
it used to work the way you say. It had problems leading me to change
it to the way it is now. I don't really remember the details but I
remember being pretty sure this way was better and I know I have had
many fewer complaints about it recently.

I don't actually see the problem right now - if the window is
undecorated, fullscreen size, and on top of everything including the
panel, what else do you want?

In any case, it's fully impossible to magically figure this out 100% 
of the time, so at some point the answer has to be screw it, fix the
applications to use the fullscreen hint.

Is the problem that the window gets moved down (not at 0,0)? That's 
probably a new bug introduced on HEAD, there's already an open bug 
about that (to re-add the exception to the "not overlapping panel"
constraint for windows larger than the area between the panels).

speaking of which the fullscreen_size heuristic is really broken.  A
coworker pointed this out to me: try putting a menu panel at the top
and another panel at the bottom.  Maximize a window -- often it will
decide the maximized window is fullscreen size and give it fullscreen
window stacking, which is highly suboptimal to say the least.  I'm not
quite sure why this is happening since the window decorations ought to
prevent it, but it definitely does happen.  As a test adding return
FALSE to the beginning of window_is_fullscreen_size in stack.c fixed
that bug.

should definitely open a bug for that, it must be something silly.

I don't see the window getting placed on top of the panel; the
fullscreen detection code affects only stacking order and not
position.  When I have a panel at the top of the screen, the window is
pushed below that, although it appears to be left at it's original
size.  Perhaps if the panel was at the bottom things would "just work"
as you indicate.

Sounds like the real bug is the position constraints thing.

Ok.  I can put a call to the 'is this full-sized' function in that
part of the code and see if it works, instead of the sledge hammer
approach I'm currently using.

*** This bug has been marked as a duplicate of 106740 ***