Issue 110881

Summary: Impress slideshow mode does not work properly since it doesn't use _NET_WM_STATE_FULLSCREEN
Product: gsl Reporter: ccheney <ccheney>
Component: codeAssignee: wolframgarten
Status: CLOSED FIXED QA Contact: issues@gsl <issues>
Severity: Trivial    
Priority: P3 CC: dannybaumann, gleppert, issues, philipp.lohmann, thb
Version: OOO320m12   
Target Milestone: OOo 3.3   
Hardware: All   
OS: Linux, all   
URL: http://launchpad.net/bugs/525807
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---

Description ccheney 2010-04-14 16:10:40 UTC
When trying to put Impress into full screen mode it does not draw over the top
and bottom bars in Ubuntu. A Compiz developer mentioned that this was because
OOo does not use the _NET_WM_STATE_FULLSCREEN property and the hack to make OOo
draw fullscreen anyway that compiz used to implement they have dropped due to it
causing problems with other applications.
Comment 1 ccheney 2010-04-14 16:23:13 UTC
Replace fullscreen with slideshow mode in above comment, though I just tested
Writer and it also happens when you attempt to put it into fullscreen mode, so
it seems to happen for both. This bug might better belong on framework, I am not
certain.
Comment 2 philipp.lohmann 2010-04-14 17:16:57 UTC
This bug would belong to gsl.

If _NET_WM_STATEFULLSCREEN is not used, you're using a multiple monitor
(Xinerama) configuration. On these _NET_WM_STATEFULLSCREEN does not work
reliably since some window managers make it mean "full screen" = whole root
window = all monitors, whereas others interpret "full screen" = "use all the
monitors the window is currently on" or "one of the monitors the window is
currently on".

On single monitor configurations _NET_WM_STATEFULLSCREEN is well defined and is
used by OOo.
Comment 3 philipp.lohmann 2010-04-14 17:20:38 UTC
however someone would have to come up with a better idea that works reliably on
old WMs, too. thb wanted to change this anyway, but since we want to support
older distributions as well, there is currently to my knowledge no really good
way to use _NET_WM_STATEFULLSCREEN in xinerama configurations.
Comment 4 traviswatkins 2010-04-14 17:36:39 UTC
I'm running on a single monitor system and OOo is _not_ using _NET_WM_STATE_FULLSCREEN.
Comment 5 philipp.lohmann 2010-04-14 18:00:17 UTC
Mine does. What window manager are you using (I use compiz at the moment). If
you use xdpyinfo, are you sure there is no XINERAMA extension present ? What
desktop are you running  (that would decide whether OOo uses its gtk plugin or
its generic X11 code for this, though in both cases _NET_WM_STATE_FULLSCREEN
gets used when there is no or just one XINERAMA screen). Also which OpenOffice
are you using ? I'm not sure whether Ubuntu uses plain OOo or some forked version.
Comment 6 philipp.lohmann 2010-04-14 18:22:37 UTC
Sorry, at the moment I don't see how OOo could not set _NET_WM_STATEFULLSCREEN
in non xinerama case (although it might try to do this as a root window message
which might get ignored). I'll have to  debug this on Ubuntu.
Comment 7 ccheney 2010-04-14 21:33:07 UTC
Ubuntu does use ooo-build but a grep of ooo-build doesn't show that it has
messed with the setting of _NET_WM_STATEFULLSCREEN .

My system also only has a single active screen, at least as far as I know
anyway, but it is a laptop so potentially has access to more screens.
Comment 8 ccheney 2010-04-14 21:49:00 UTC
Oh yea the default window manager on Ubuntu is compiz 0.8.4 and they
specifically mentioned to me that they recently removed support for broken apps
that did not set _NET_WM_STATE_FULLSCREEN properly.
Comment 9 ccheney 2010-04-14 21:54:40 UTC
BTW Ubuntu desktop is Gnome with Compiz.

Oh and additionally I checked xdpyinfo and XINERAMA is present. I think it is
enabled by default on all my systems by default. I think maybe Xorg does this by
default now. At least I know I don't have any manually configured Xinerama or
multihead systems and its enabled on all of them and also have no xorg.conf
files, so completely set up automatically.

My 4 systems I tested have:

2 Intel graphics (a 945G and 4500)
1 Nvidia graphics (binary only driver for 7600)
1 ATI graphics (with floss xorg driver)

of those

2 Ubuntu 9.10 systems
2 Ubuntu 10.04 systems

I can do further testing if desired.
Comment 10 thb 2010-04-14 22:04:41 UTC
yep, my proposed changes are for multi-monitor/xinerama cases only. FWIW, patch
is at issue 107249.
Comment 11 ccheney 2010-04-19 16:19:30 UTC
So if I understand correctly there isn't any known way to fix this issue for non
multimonitor setups that also have XINERAMA enabled?
Comment 12 ccheney 2010-04-19 17:16:14 UTC
I verified with the Ubuntu Xorg maintainer that he did not make any changes to
force enable Xinerama on systems so this is likely to be a widespread problem
soon for Linux systems, if it isn't already.
Comment 13 philipp.lohmann 2010-04-19 17:38:30 UTC
Not currently. With the fix attached to issue 107249 it works with metacity, but
compiz refuses to cooperate. As soon as the presentation window is made
fullscreen (using gtk_window_fullscreen or the equivalent non-gtk functionality)
Compiz 0.8.4 immediately removes the fullscreen state again from the window (you
can see this in the windows state signal handler just fine: first a transition
to fullscreen, immediately followed by a transition from fullscreen). Which
means you end up with a window that is not quite a fullscreen window.

I might add that I wasted lots of time downloading first the nightly build
mentioned in the launchpad report - which does not even install - and then the
beta of 10.04 - which after install does not boot.

At least compiz on 9.10 shows the reported behavior. I do not yet know why
compiz behaves so uncooperative (well, I do, it's because it has its bugs, too,
I do not know yet however what exactly causes it to remove fullscreen state again).

This is by the way on a 2 monitors xinerama setting; but I suspect the same
happens with one monitor. I'll poke a little further around in this.
Comment 14 philipp.lohmann 2010-04-19 17:45:52 UTC
And this happens without xinerama as well. Compiz just removes the fullscreen
state again without being asked to. Which also explains why this happens in
single monitor configurations.
Comment 15 thb 2010-04-19 18:51:10 UTC
@ccheney: so then by all means, let's fix this in compiz? I'll poke David for
any insight - do you have this patched?
Comment 16 philipp.lohmann 2010-04-19 19:53:33 UTC
I made a little progress; Compiz seems to react to min/max size settings. Which
are unclear when fullscreen state is active at the same time; the problem here
is that a not sizeable window (which our full screen presentation is) has equal
min and max sizes.

The current code more or less assumes that min/max sizes will be ignored in
fullscreen conditions, however that may be not the case here - and may be a
debatable assumption.
Comment 17 philipp.lohmann 2010-04-19 20:08:55 UTC
That alone does not seem to be IT. While setting a max size within the gtk
plugin makes the fullscreen work, in the generic plugin it does not seem to
improve things. Here it is "mostly works not - only sometimes" from the beginning.

Don't know what compiz really wants yet.
Comment 18 philipp.lohmann 2010-04-20 18:28:55 UTC
The improvement for gtk will make its way into 3.2.1 with issue 107249 (that
should make at least ubuntu happy, where kubuntu will probably still suffer the
problem). I'll keep this one for the generic code vs. compiz, but frankly at the
moment I don't have a clue why that does not work. Even more so since once or
twice in ten tries it will work, pointing to some kind of race condition which I
cannot seem to figure out.
Comment 19 dannybaumann 2010-05-17 14:33:42 UTC
@pl:
Compiz doesn't need any max or min size for allowing an app to go fullscreen.
Was the "legacy fullscreen workaround" in the workarounds plugin enabled during
the testing? It should be disabled, because the point of this bug report is to
remove that kind of workaround in compiz. The legacy fullscreen one is a
particular ugly one which I'd like to remove rather yesterday than tomorrow.

Also, I don't see why the usage of _NET_WM_STATE_FULLSCREEN should be avoided in
the Xinerama case. You could _at least_ check for support for
_NET_WM_FULLSCREEN_MONITORS
(http://standards.freedesktop.org/wm-spec/wm-spec-latest.html#id2552578) in
_NET_SUPPORTED and use _NET_WM_STATE_FULLSCREEN if FULLSCREEN_MONITORS is
supported (and you could even use _NET_WM_FULLSCREEN_MONITORS to control the
monitor the slide show is running on).

Another thing: Can you please create a minimal test case for a window which you
think should be fullscreen, but is unfullscreened right after (if that still
happens without legacy fullscreen support)?

And the last thing[TM]: Please open a bug report against compiz
(bugs.opencompositing.org) if you find out any compiz weirdness during ooo
development instead of adding workarounds to your codebase which we (as compiz
developers) need to work around again. I can't fix problems I am not aware of ;-)

Thanks,

Danny
Comment 20 philipp.lohmann 2010-05-17 15:02:17 UTC
_NET_WM_STATE_FULLSCREEN at the time this code was written needed to be avoided,
since it was at the time completely undefined what that would mean in a multiple
monitor case. Kwin (at that time) happened to extend the window to all monitors
whereas metacity made it appear on one screen (involving some positioning logic
AFAIK).

Anyway that does not seem to apply anymore which is why _NET_WM_STATE_FULLSCREEN
will be used also in the Xinerama case when the fix for issue 107249 gets
integrated; (which is the case already on the 3.2.1 code line with OOO320m17).
For your simple test case you could use said OOO320m17 (they called it 3.2.1 RC1
I think). The problem I had was then reproducible like this:

- have a (at least) dual screen setup
- set environement variable SAL_USE_VCLPLUGIN to "gen" in a shell (this forces
the generic X11 plugin to be used which still shows the described problem)
- from that shell start OOo
- create a new empty presentation
- start the presentation in full-screen mode (e.g. by pressing F5)
-> see the presentation window, it is not full screen anymore but lies beneath
the gnome menus on top of the presentation window. The layering problem should
also occur on non gnome of course, but the testbed here was Ubuntu 9.10. xprop
also shows that the fullscreen state has not been set.

On a side note: _NET_WM_FULLSCREEN_MONITORS is not even a standard yet, it's
only part of the draft 1.4. And the baseline we run on is much older than
_NET_WM_FULLSCREEN_MONITORS ;-)
Comment 21 dannybaumann 2010-05-17 15:10:12 UTC
You don't need to justify for the past, but please use the new stuff in the
future :)
Are there binary builds for that RC1? If yes, where can I download them? If no,
building ooo from source doesn't exactly sound like a 'simple' test case ;-)
Comment 22 philipp.lohmann 2010-05-17 15:23:06 UTC
Those builds should be at http://download.openoffice.org/all_rc.html#untested-full

I'll have to agree that building OOo out of the box is not a simple testcase :-)
Comment 23 dannybaumann 2010-05-17 15:45:14 UTC
Hmm, impress works fine for me in that case. _NET_WM_STATE_FULLSCREEN is set for
the window. Running 'set | grep SAL' in the terminal I ran ooo from gives
'SAL_USEVCLPLUGIN=gen'. WM is compiz from 0.8 branch HEAD (essentially compiz
0.8.6), distro is Fedora 12, with Nvidia binary driver (-> Twinview) and two
monitors (1280x1024 + 1680x1050) and KDE 4.4.

It also works both with and without the legacy fullscreen workaround being
enabled. It would be interesting to find out why it's failing for you, but not
for me. From the top of my head, I think workarounds is also about the only
plugin messing with _NET_WM_STATE_FULLSCREEN.
Comment 24 philipp.lohmann 2010-05-17 15:49:58 UTC
you have SAL_USEVCLPLUGIN where it should be SAL_USE_VCLPLUGIN. The difference
should be visible; you get the generic (aka "battleship grey") colors in that
case whereas with the normal gtk plugin you get gtk theming.
Comment 25 dannybaumann 2010-05-17 16:04:29 UTC
Ah, yes, I see, sorry for the typo. Now I get segfaults after clicking finish in
the new presentation wizard :-/
Comment 26 philipp.lohmann 2010-05-17 16:23:50 UTC
Oh great :-( I can try to come up with a small X client that produces the same
effect, but please don't expect it today or this week. Actually I'm more worried
about that segfault in our RC.
Comment 27 dannybaumann 2010-05-17 16:52:12 UTC
This is the backtrace, FWIW. Maybe I'm doing something wrong...

(gdb) bt
#0  0x00a721ea in elf_machine_rel (scope=0x8149d48, reloc_mode=1,
consider_profiling=0) at ../sysdeps/i386/dl-machine.h:344
#1  elf_dynamic_do_rel (scope=0x8149d48, reloc_mode=1, consider_profiling=0) at
do-rel.h:120
#2  _dl_relocate_object (scope=0x8149d48, reloc_mode=1, consider_profiling=0) at
dl-reloc.c:268
#3  0x00a79aa6 in dl_open_worker (a=0xbfffa410) at dl-open.c:367
#4  0x00a75526 in _dl_catch_error (objname=0xbfffa438, errstring=0xbfffa434,
mallocedp=0xbfffa43f, operate=0xa79800 <dl_open_worker>, args=0xbfffa410) at
dl-error.c:178
#5  0x00a79423 in _dl_open (file=0xbfffa658
"/tmp/opt/openoffice.org3/program/../basis-link/program/libcomphelp4gcc3.so",
mode=-2147483391, caller_dlopen=0x12a6a9, nsid=<value optimized out>, argc=2,
argv=0xbfffee04, env=0x804d4f8)
    at dl-open.c:583
#6  0x00888c3b in dlopen_doit (a=0xbfffa5f0) at dlopen.c:67
#7  0x00a75526 in _dl_catch_error (objname=0x804d4ec, errstring=0x804d4f0,
mallocedp=0x804d4e8, operate=0x888ba0 <dlopen_doit>, args=0xbfffa5f0) at
dl-error.c:178
#8  0x0088903c in _dlerror_run (operate=0x888ba0 <dlopen_doit>, args=0xbfffa5f0)
at dlerror.c:164
#9  0x00888b71 in __dlopen (file=0xbfffa658
"/tmp/opt/openoffice.org3/program/../basis-link/program/libcomphelp4gcc3.so",
mode=257) at dlopen.c:88
#10 0x0012a6a9 in ?? () from
/tmp/opt/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3
#11 0xbfffa658 in ?? ()
#12 0x00000101 in ?? ()
#13 0x0000004a in ?? ()
#14 0x0012a67d in ?? () from
/tmp/opt/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3
#15 0x002c5c9c in ?? () from
/tmp/opt/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3
#16 0x002c5c9c in ?? () from
/tmp/opt/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3
#17 0xbfffb668 in ?? ()
#18 0x0012a722 in osl_loadModule () from
/tmp/opt/openoffice.org3/program/../basis-link/ure-link/lib/libuno_sal.so.3
Comment 28 philipp.lohmann 2010-05-17 17:01:07 UTC
That looks like a missing symbol to me - strange.
Comment 29 philipp.lohmann 2010-05-17 18:40:27 UTC
Will look at this when my Linux box boots again :-( Which install set of those
did you use and on which OS ?
Comment 30 dannybaumann 2010-05-18 07:55:51 UTC
Assuming that by "those", you mean the RC1 install package: I used the 32bit RPM
package
(http://download.services.openoffice.org/files/extended/3.2.1rc1/OOo_3.2.1rc1_20100506_Linux_x86_install-rpm-wJRE_de.tar.gz).
Distro is Fedora 12.
Comment 31 philipp.lohmann 2010-05-18 19:01:46 UTC
strange, that install set seems to work on my FC12. However you seem to have
installed in /tmp, so a difference might be in the way we install; I used

"rpm -vh --install --dbpath <somehere>/.rpm --nodeps --prefix <somewhere> <where
the rpms are>/*.rpm"

Using /tmp as <somewhere> however worked fine for me, so I'm probably doing
something different than you.

Seeing the missing symbol kind of stack I got the idea that perhaps you're
running into a problem with SELinux which perhaps does not allow a library to be
loaded in that context, but that's just a wild guess.
Comment 32 dannybaumann 2010-05-19 07:55:35 UTC
I used the setup program of the package, which seems to do a similar thing.
selinux is disabled on my system. With your way of installation, I get the same
behaviour as with the installer.
Comment 33 philipp.lohmann 2010-05-19 10:39:49 UTC
:-(  Ok, I don't have a clue what's going wrong then. I'll try to come up with
an X client reproducing the problem I'm seeing with OOo. Sorry for wasting your
time.
Comment 34 philipp.lohmann 2010-05-25 15:02:40 UTC
Not setting the ancient motif wm hint on the full screen presentation window
does the trick, although I don't know why. Therefore I'll set this issue to "fixed".

However a simple X client that creates a window with the same _NET_WM_STATE,
_MOTIF_WM_HINTS, _NET_WM_WINDOW_TYPE, WM_HINTS, WM_NORMAL_HINTS as the
presentation window of OOo does NOT reproduce the problem, which leaves some
interaction with other (more dynamic) properties. I'm sorry, I can not at the
moment come up with a simple sample program showing the issue OOo seems to have
in interaction with compiz. I'll settle for the "solution" of not setting the
mwm hint.

fixed in CWS vcl112
Comment 35 philipp.lohmann 2010-06-08 09:53:05 UTC
please verify in CWS vcl112
Comment 36 wolframgarten 2010-06-10 12:40:33 UTC
Verified as seen on the screen of pl.
Comment 37 caolanm 2010-08-11 15:51:29 UTC
As an aside: https://bugzilla.redhat.com/show_bug.cgi?id=623191 has a standalone
test-case which is pretty much what that gtk vclplug does, and does rather odd
things for me on compiz 0.8.2, which might be related to this
Comment 38 gleppert 2010-08-22 20:38:47 UTC
Will this issue be fixed in OO.org 3.3? 
At least in Beta 1 the issue is not fixed. The issue as described is still
there. In presentation mode I always have the gnome bars.

System: Ubuntu 4.10 with Intel Graphics X3100. OpenOffice.org 3.3. Beta 1 from
the official OpenOffice Website.
Comment 39 gleppert 2010-08-22 21:07:44 UTC
As I have seen CWS vcl112 should already be integrated in Beta 1. Anyhow, the
problem is still there. Issue is not fixed.
Comment 40 wolframgarten 2010-08-23 07:59:09 UTC
vcl112 is integrated into DEV300_m84. @pl: could you have a look iof the fix
really arrived in beta version? Thanks in advance.
Comment 41 dannybaumann 2010-08-23 10:04:39 UTC
Closer inspection of the test case in the RH Bugzilla points towards an X event
timing problem in Gtk+, namely that the _NET_WM_STATE property notify event
arrives after the map request event of the window. Acknowledgement by the Gtk+
people is yet missing, though.
Comment 42 philipp.lohmann 2010-08-23 10:33:40 UTC
I can confirm the fix is in, but I see the same problem on Gnome/Compiz using
OpenSuSE 11.3. This behavior changed - yet again :-( - from the compiz version
shipped with OpenSuSE 11.2.  Oh the fun one has with window managers.
Comment 43 dannybaumann 2010-08-23 10:36:34 UTC
The code in compiz dealing with fullscreen handling hasn't been touched since
support for _NET_WM_FULLSCREEN_MONITORS went in, which was quite some time (at
least one year, likely more) ago. This points towards the bug being not actually
fixed - see the RH bug entry ;)
Comment 44 philipp.lohmann 2010-08-23 10:42:40 UTC
look, it's not really complicated. The code calls  gtk_window_fullscreen now.
Besides this is on single monitor, where there wasn't even a problem before. And
if compiz hadn't changed, then why do I see a title bar all of a sudden on the
presentation (that I didn't want either ?
Comment 45 dannybaumann 2010-08-23 10:59:33 UTC
Because gtk_window_fullscreen() doesn't seem to work as indended. Please read my
comment #8 in the RH Bugzilla entry
(https://bugzilla.redhat.com/show_bug.cgi?id=623191#c8). I am not refering to
that bugzilla entry without reason ;)
Comment 46 philipp.lohmann 2010-08-23 11:14:28 UTC
That seemed like a good argument, but only until I switched to our generic X
code where setting _NET_WM_STATE_FULLSCREEN doesn't work right anymore either.
Then again the mwm hints (which shouldn't have any influence in the first place)
that were not supposed to be there anymore have appeared again.
Comment 47 dannybaumann 2010-08-23 11:24:53 UTC
To be honest, I don't understand what you mean here. Do you want to say that you
still believe that compiz is broken? If so,
- What exactly is the generic code doing for setting the fullscreen state?
- What compiz versions are shipped with OS 11.2 and 11.3?
Comment 48 philipp.lohmann 2010-08-23 11:29:00 UTC
At the moment I don't really know. At least the MWM hint we're setting again
seems to be odd since I explicitly wanted to not do that on fullscreen windows.

As for how OOo sets fullscreen in the generic code: as _NET_WM_STATE on the
window in question if it is not shown yet (which should be the normal case I
think) or as root window message, if the window is already shown.
Comment 49 philipp.lohmann 2010-08-23 13:08:03 UTC
Ok, the MWM hints I understand now; this fix was incomplete. I still don't
understand why not setting a MWM hint (or deleting the property before going
fullscreen) should change anything, but at least that does seem to do the trick
for our generic X11 code (which runs also on KDE). reopening this issue for at
least that commit.

Alas that fixes only the generic X case, the gtk case is still broken - not
surprising since dannybaumann says, it's gtk_window_fullscreen itself that is
the culprit. I'll try to find a workaround for that, but I'm not hopeful
Comment 50 dannybaumann 2010-08-23 13:09:53 UTC
You can try calling gtk_window_fullscreen after gtk_window_show, from my
understanding of the Gtk code this could avoid the race condition (but at the
same time cause the window to not be fullscreen initially).
Comment 51 philipp.lohmann 2010-08-23 13:25:14 UTC
thanks but that didn't work.
Comment 52 philipp.lohmann 2010-08-23 13:51:23 UTC
and delaying that until after the map signal didn't work either.
Comment 53 philipp.lohmann 2010-08-23 14:44:08 UTC
Also while I can confirm that caolan's test program indeed reproduces the
problem and can be made to work with both mentioned workarounds, the same
workarounds alas do not work with in OOo :-(

replacing gtk_window_fullscreen with an appropriate XSendEvent after either map
or even expose message did not result in the desired fullscreen state.
Comment 54 philipp.lohmann 2010-08-24 13:42:47 UTC
... it does however if OOo doesn't set a bogus max size and sets the gtk window
to resizable again. Ok, I'm blockheaded, but does it have to show so clearly ?
dannybauman: I guess I owe you an apology ... again.

I know I have it seen working the last time around this issue was set to fixed
(I have a witness after all), but how that came to be I don't really know.
Comment 55 philipp.lohmann 2010-08-24 17:54:34 UTC
@wg: please verify (again, sorry) in CWS ooo33gsl07
Comment 56 wolframgarten 2010-08-26 10:28:14 UTC
Verified in CWS. Looks promising on pl's machine ;-)