Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Impress slideshow mode does not work properly since it doesn't use _NET_WM_STATE_FULLSCREEN|
|Status:||CLOSED FIXED||QA Contact:||issues@gsl <issues>|
|Priority:||P3||CC:||dannybaumann, gleppert, issues, philipp.lohmann, thb|
|Target Milestone:||OOo 3.3|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
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 ;-)