App...Well?  Or the menu at the top?  We shouldn't be showing a panel at all in this case; I'm not sure what's going on with flash in this case.

Debugging...

Ok with a debugger I'm seeing:

meta_stack_tracker_sync_stack (which emits 'restacked', from which we do the chrome visibility computations), being called *before* stack_do_relayer, which is what computes window->layer and should set META_LAYER_FULLSCREEN.

Inside meta_window_new_with_attrs, we're getting the NET_WM_FULLSCREEN property and setting window->fullscreen = TRUE (but don't touch window->layer).  A bit later still inside meta_window_new_with_attrs, we call stack_sync_to_server which then calls stack_do_relayer.

However, stack_do_relayer does not give the window META_LAYER_FULLSCREEN because it's not the window->display->expected_focus_window, which is only set when we receive a focus event.

Later when we get the focus event back from X, we do update the layer.  However we don't emit a meta_screen_restacked after this.

So...what the chrome.js really wants to know is when we get a "relayering".  But, I'm actually not sure what the rationale is here behind checking whether the window is the "expected focus window".  Looking at git annotate of src/core/stack.c in original metacity, I see:

+2005-07-31  Elijah Newren  <newren@gmail.com>
+
+       * src/stack.c (is_focused_foreach, get_standalone_layer): use only
+       the expected_focus_window instead of both the focused_window and
+       the expected_focus_window.  Removes an infinite flicker loop in
+       sloppy and mouse focus, and an ugly one time flicker in click to
+       focus.  Fixes #311400.
+

I don't understand why FULLSCREEN isn't set simply if the window is at the top of the stack, and it has the FULLSCREEN property.

Created attachment 153362 [details] [review]
Don't show chrome when a fullscreen window is open

This patch fixes this by correcting the fullscreen check, see IRC log for details:

--------------
<drago01> walters: it just assumes fullscreen = fullscreen period 
<drago01> walters: might want to check if the window is on the primary monitor
<walters> drago01: right that's the main goal of the current code i believe
<drago01> walters: ok
<drago01> walters: ok what is happening is this:
<drago01> walters: those apps just set _NET_WM_FULLSCREEN and let the wm do the rest ... they do not change there position so windows[i].x + windows[i].width >= primary.x + primary.width fails
<drago01> walters: the window is located somewhere on primary but width and height is the same as the screen
<walters> ah
<walters> hmm
<drago01> so the we should only check if x and y are on primary (and patch mutter to tell us when a window is NET_WM_FULLSCREEN_MONITORS
<drago01> (or what ever the "fullscreen on all screens thing is called")
<drago01> because you can't really have a fullscreen window that is between two screens
<drago01> so the the check isn't correct anyway
<jnettlet> drago01: unless you are running the nvidia driver
<walters> danw: did you have any thoughts on this?
<drago01> jnettlet: afaik they fixed this
<halfline> jnettlet: so i've seen a fullscreen bug where my browser was stuck in fullscreen mode with no way to get out of it and my huludesktop's fullscreen mode had a panel with no way to get rid of it
<halfline> it's like hulu's fullscreeniness got transferred to chromium
<drago01> walters: in fact a check like x and y is on primary and width and height < primary width and height should do it
<drago01> walters: should also cover net_wm_fullscreen monitor
* hyperair hat die Verbindung getrennt (Ping timeout: 600 seconds)
<walters> drago01: i don't see that hint in the spec
<drago01> walters: it is "new" let me look up the correct name
<jnettlet> drago01: walters: owen suggested that we create a new MetaStack Layer that is where non-window actors get drawn.
<walters> halfline: i think it's a race condition; there is this "expected focus" handling
<jnettlet> it can sit below the OverRide Redirect and Fullscreen layers
<danw> for the override_redirect case we have to keep the current check. but for fullscreen, yeah, just checking x and y, and not width and height sounds right
<owen> jnettlet: No, I didn't actually suggest that, exactly
<drago01> walters: _NET_WM_FULLSCREEN_MONITORS can't find it in the spec either might be not part of it yet but almost all common wms added support
<owen> jnettlet: And it doesn't help for this since we have to change the input shape
<walters> drago01: btw could you paste this conversation to the bug if you're going to attach a patch?
------------

Comment on attachment 153362 [details] [review]
Don't show chrome when a fullscreen window is open

>In this case x + width is almost always > primary.x + primary.height (same goes for y).

That's not why it's failing though, it's failing because of the "windows[i].x <= primary.x" check.

Also, there are multiple typos in the message. Also, it's nice to wrap the message to 72-column lines.

Currently the check in chrome.js checks if a window is on the
primary screen by checking its coordinates, width and height.

This check misses the case where windows just set
_NET_WM_FULLSCREEN without changing their position and
size (examples are Flash and ooimpress's presentation window).

Fix this by separating the check for fullscreen windows from the
override redirect one, and only check whether the window is
anywhere on the primary screen in the fullscreen case.

https://bugzilla.gnome.org/show_bug.cgi?id=597271

Comment on attachment 153362 [details] [review]
Don't show chrome when a fullscreen window is open

Commited as 2d57404, with a fixed commit message.

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