Bug 623191

Created attachment 438208 [details]
standalone demo

upstream bugzilla (http://bugs.opencompositing.org) seems dead/down :-(

FWIW, the demo application works fine for me, using compiz off the HEAD of the 0.8 branch (which essentially is 0.8.6).

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

"FWIW, the demo application works fine for me, using compiz off the HEAD of the
0.8 branch (which essentially is 0.8.6)."

I quickly build the 0.8.6 rawhide rpm, which admittedly has some patches in it, and when I ran the demo on an empty screen it initially looked good. Until I realized that...

a) the gnome panels were drawn above the full-screen window
b) when I added some extra windows to my screen to fill it up and then re-ran it then the window is positioned off screen.

where the same source commented removal of decoration hint disable or removal or resizing disable makes it "work" as desired by fitting it over everything else and anchored at 0, 0

(In reply to comment #6)
> "FWIW, the demo application works fine for me, using compiz off the HEAD of the
> 0.8 branch (which essentially is 0.8.6)."
> 
> I quickly build the 0.8.6 rawhide rpm, which admittedly has some patches in it,

If the patches equal those of the Fedora package, I don't think they'll have any influence to this problem.

> and when I ran the demo on an empty screen it initially looked good. Until I
> realized that...
> 
> a) the gnome panels were drawn above the full-screen window
> b) when I added some extra windows to my screen to fill it up and then re-ran
> it then the window is positioned off screen.
> 
> where the same source commented removal of decoration hint disable or removal
> or resizing disable makes it "work" as desired by fitting it over everything
> else and anchored at 0, 0    

Interesting. It doesn't do that here. Instead it sometimes spans both of my monitors, although a fullscreen window should only span one of them. I wonder if the demo program setting the minimum size to the screen size (clearly not taking multi-monitor configurations into account) is related (1280x1024 + 1680x1050 -> screen size 2960x1050). I'll check that out.

It looks like it's no compiz problem, after all, but instead Gtk+ is to blame. An excerpt of xprop with the offending lines removed looks like this:

WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_RESIZE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_MAXIMIZE_HORZ, _NET_WM_ACTION_MAXIMIZE_VERT, _NET_WM_ACTION_FULLSCREEN, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN

while the same excerpt with the offending lines in looks like this:

WM_STATE(WM_STATE):
                window state: Normal
                icon window: 0x0
_NET_WM_DESKTOP(CARDINAL) = 0
_NET_WM_ALLOWED_ACTIONS(ATOM) = _NET_WM_ACTION_MOVE, _NET_WM_ACTION_STICK, _NET_WM_ACTION_MINIMIZE, _NET_WM_ACTION_CLOSE, _NET_WM_ACTION_CHANGE_DESKTOP, _NET_WM_ACTION_ABOVE, _NET_WM_ACTION_BELOW
_NET_WM_STATE(ATOM) = 

As you can see, in the latter case Gtk+ doesn't set the window to have fullscreen state properly, thus compiz can't handle it like a normal fullscreen window.
From first inspection, it looks like Gtk+ sees the window is unmapped and tries to set the STATE property by itself, which conforms to EWMH for unmapped windows. The problem is that the MapRequest event triggered by gtk_window_show is delivered earlier than the PropertyNotify event triggered by gtk_window_fullscreen for some Gtk internal reason, so compiz thinks that the application tries to set the property for a managed window and ignores that change (which also conforms to EWMH, see the first few sentences of http://standards.freedesktop.org/wm-spec/wm-spec-1.3.html#id2507241).

For getting this problem fixed, it looks like you'll need to ask Gtk+ people to make sure that any pending _NET_WM_STATE property changes are sent out on gtk_window_show before the actual XMapWindow() call.

caolanm->mclasen: See #8, agree that this a gtk2 issue ?

Thank you for your bug report. This issue was evaluated for inclusion
in the current release of Red Hat Enterprise Linux. Unfortunately, we
are unable to address this request in the current release. Because we
are in the final stage of Red Hat Enterprise Linux 6 development, only
significant, release-blocking issues involving serious regressions and
data corruption can be considered.

If you believe this issue meets the release blocking criteria as
defined and communicated to you by your Red Hat Support representative,
please ask your representative to file this issue as a blocker for the
current release. Otherwise, ask that it be evaluated for inclusion in
the next minor release of Red Hat Enterprise Linux.

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

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

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

Red Hat Enterprise Linux 6 is in the Production 3 Phase. During the Production 3 Phase, Critical impact Security Advisories (RHSAs) and selected Urgent Priority Bug Fix Advisories (RHBAs) may be released as they become available.

The official life cycle policy can be reviewed here:

http://redhat.com/rhel/lifecycle

This issue does not meet the inclusion criteria for the Production 3 Phase and will be marked as CLOSED/WONTFIX. If this remains a critical requirement, please contact Red Hat Customer Support to request a re-evaluation of the issue, citing a clear business justification. Note that a strong business justification will be required for re-evaluation. Red Hat Customer Support can be contacted via the Red Hat Customer Portal at the following URL:

https://access.redhat.com/