Created attachment 17554 [details]
Screenshot

I'm not sure if it's possible to fix it :/ Not a wm expert though.

Re fullscreen mode, note that the marked up version of the HIG says the
following:

"Leave Fullscreen button should be placed in the upper right hand corner
of the window. The button should disappear after the mouse is unused for
5 seconds, and should appear again when the moused is moved. 

Alternately, in applications where the mouse is used frequently in full
 screen mode, all but a two pixel row of the button may be slid off the 
top of the screen. The button should slide back on the screen when the 
mouse moves near it."

http://developer.gnome.org/projects/gup/hig/hig-diff/menus.html#menu-type-menubar

I see no real problem with the current method, this is just a note :)

Yeah but browser is a particular case, because it has the toolbar at
the top.
Considering the main author of the HIG suggested current impl, I guess
we should be safe ;)

Because the button is in an override-redirect window, the
window manager never sees it. Override-redirect is set
because GTK_WINDOW_POPUP is used.

For this, and other things, I think we need an internally floating
container. I tried to make one back in April, but didn't get very
far:

http://mail.gnome.org/archives/gtk-devel-list/2003-April/msg00225.html

If I can come up with one, it'll be a GtkBin subclass and I'll let
you know.

That would really rock. We had the same problem with toolbar editor ...

http://lxr.mozilla.org/mozilla/source/widget/src/gtk2/mozcontainer.h
http://lxr.mozilla.org/mozilla/source/widget/src/gtk2/mozcontainer.c

These does something similar, in case you need ispiration :)

Those are pretty funny. They've basically reimplemented GtkFixed
with a little bit of modification. The only API differences are
width and height in the move function and the scroll_update; both
mere conveniences, IMO.

http://developer.gnome.org/doc/API/2.0/gtk/GtkFixed.html

But that isn't what I had in mind. The important function in
the API I envision is:

void cg_floater_attach (CGFloater     *floater,
                        GtkWidget     *widget,
                        GtkAnchorType  anchor,
                        gint           x_offset,
                        gint           y_offset);

Though, maybe it should take a GdkWindow for the second argument.
(CG is the namespace I use for my pet widgets.)
For epiphany, going to fullscreen would invoke something like:

go_fullscreen (EphyThing *thing)
{
  GtkWidget *floater;
  GtkWidget *button;

  floater = cg_floater_new ();

  cg_floater_attach (CG_FLOATER (floater), GTK_WIDGET (thing),
                     GTK_ANCHOR_SOUTH_WEST, 0, 0);

  button = gtk_button_new_with_label ("Exit Fullscreen");
  g_signal_connect (button, "clicked",
                    G_CALLBACK (exit_fullscreen), thing);
  gtk_container_add (GTK_CONTAINER (floater), button);

  gtk_widget_show_all (floater);
}

I have a bad hack already that fails to allocate properly or draw
anything, but at least I can see the little overlayed window. :-)

The toolbar editor may be more complicated. If its window is
going to exceed the boundaries of the main window, then you have
to either use an override-redirect or get window manager support.
Using the override-redirect is tricky and resource intensive when
done right - basically, you have to write a little window manager.
Not that I've much experience, but I've never seen it done right.

Getting window manager support for "drawers" (in MacOS X-speak)
would be far better than an override-redirect.

Oh, you could also go completely cracky and use an undecorated
shaped window then . . . nah, too cracky. :-)  Well, at least
until you can convince people that window managers shouldn't
be responsible for window decorations. First, you may have to
convince them that "decorations" is a misnomer; they are window
frames and window frame controls, not decorations.

I digress.

Since Mozilla handles it's own scrollbars, you may be able to
easily change your parent of the mozilla widget to a GtkFixed
then overlay the button as the second child of that. You'll
have to be careful with allocations, requisitions, and stacking
order.

You may find this funny, but I think there's an even simpler solution.
Do pretty much what you're doing now, but before gtk_widget_show(),
do this:

gtk_widget_realize (popup);
gdk_window_reparent (popup->window, GTK_WIDGET (window)->window,
                     0, height_of_ephy_window - height_of_popup);

Of course, you'll need real values for those heights.
I've assumed the EphyWindow extends to the bottom left corner of
the screen and that is the corner where the button will be.

You may want to change update_exit_fullscreen_popup_position() to
do that.

You may have to watch for stacking or visibility changes and
gdk_window_raise() the popup's GdkWindow if the button is covered up.

Keyboard navigation, and maybe accessibility in general, remains a
problem. The more I think about that, the more using GtkFixed seems
like a good idea. :-/

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

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

In cvs the button is showed only when the window is active.