Created attachment 113152 [details] Dialog should appear while opening database. Input ID=1 ... Press "Speichern" Open the attached document. A dialog should appear for input data. (sometimes it doesen't work right, don't know why ...) Put values into the fields: ID: 1 Vorname: Big Nachname: Ben Press the button "Speichern". A messagebox should appear with a warning. Up to LO 4.0.0.1 I could see this messagebox in front of the dialog. Since LO 4.0.2.2 it appears behind the dialog. Haven't installed any version between this two, so I couldn't say the first version it appears. My System: OpenSUSE 13.2 64bit rpm Linux, KDE, many different LO-versions.
On pc Debian x86-64 with master sources updated today, I got no dialog at all. I noticed this on console: warn:legacy.osl:4617:10:scripting/source/dlgprov/dlgevtatt.cxx:521: caught an exception! in function:virtual void dlgprov::DialogSFScriptListenerImpl::firing_impl(const com::sun::star::script::ScriptEvent&, com::sun::star::uno::Any*) type: com.sun.star.script.provider.ScriptFrameworkErrorException message: The following Basic script could not be found: library: 'Standard' module: 'Module1' method: 'DatenSpeichern' location: 'document'
By running the macro directly, I got a dialog and noticed this on console: warn:legacy.osl:4617:1:basctl/source/dlged/propbrw.cxx:442: PropBrw::ImplUpdate: no view, but a document?! warn:legacy.tools:4617:1:vcl/source/window/dialog.cxx:753: Dialog::StartExecuteModal() - Parent already modally disabled, use another parent to ensure modality!
When running macro directly, I've got the messagebox in front of dialog.
Created attachment 113182 [details] Example in Calc - Messagebox appears sometimes in the background of the dialog Here another example from a user, who reported the bug in a German forum. (Reported for LO 4.3.5.2 and Ubuntu 14.04) If the dialog appears klick on one radiobutton. The press "Klick". Sometimes the messagebox appears in the backgrund. Not the same behavior as reported for the first example. There the massagebox never appears in front of the dialog on my system... (OpenSUSE 13.2 64bit rpm and different LO-Versions, including Master 2015-02-05 for LO 4.5.0.0 Alpha0)
Reproduced with attachment 113152 [details]. Warning box appears only after alt-tabbing away and back. Could not reproduce with attachment 113182 [details]. opensuse 13.2 64-bit KDE LibO: Version: 4.4.0.3 Build ID: de093506bcdc5fafd9023ee680b8c60e3e0645d7 Locale: en_US
Could confirm the buggy behavior for LO 4.3.5.2 / Ubuntu 14.04
Created attachment 113259 [details] Sreenshot
Couldn't reproduce this on Ubuntu 14.04 (LXDE), so can't bibisect. Possibly timing or window manager dependent.
I have tried to isolate the problem using the document that was attached in comment 4 (attachment 113182 [details]). It seems the problem lies in LibreOffice (or more precisely probably in the toolkit) and not in the window managers. The window gets pushed in the background by the focus stealing prevention of the window managers, but the window managers work correctly according to the EWMH spec. The problem is, that sometimes LibreOffice sends a _NET_WM_USER_TIME request with a timestamp of zero to the X-server right before mapping the window. And this tells the window manager to NOT give the window focus, when it is mapped. See: http://standards.freedesktop.org/wm-spec/latest/ar01s05.html#idm139870829932528 Especially: "The special value of zero on a newly mapped window can be used to request that the window not be initially focused when it is mapped. " Unfortunately in this case it doesn't help to configure exceptions for the focus stealing prevention as a workaround (neither in compiz nor in kwin), because when deciding if a windwow should get the focus, the _NET_WM_USER_TIME timestamp has a higher priority than the configured exception rules. I have collected X protocol traces of communication between LibreOffice and the X server (using the xtrace tool), which show the problem. I will attach those after this comment.
Created attachment 113346 [details] X protocol trace when the message box gets the focus This is the X protocol trace when the message box correctly gets the focus. The message box had the window ID 0x04e00641. A couple of line before the MapWindow request 002:<:1ad3: 8: Request(8): MapWindow window=0x04e00641 there is the _NET_WM_USER_TIME request, which sets a sensible timestamp: 002:<:1ac9: 28: Request(18): ChangeProperty mode=Replace(0x00) window=0x04e00641 property=0x147("_NET_WM_USER_TIME") type=0x6("CARDINAL") data=0x2a107ceb; So in this case everything is working as expected, and the message box gets the focus.
Created attachment 113347 [details] X protocol trace when the message box does not get the focus This is the X protocol trace when the message box doesn't get the focus. The message box had the window ID 0x04e00628. A couple of lines before the MapWindow request 002:<:1a6e: 8: Request(8): MapWindow window=0x04e00628 there is the _NET_WM_USER_TIME request, which sets the timestamp to zero: 002:<:1a64: 28: Request(18): ChangeProperty mode=Replace(0x00) window=0x04e00628 property=0x147("_NET_WM_USER_TIME") type=0x6("CARDINAL") data=0x00000000; So in this case the window manager has to prevent the window from getting the focus and pushes it in the background.
Vasily Melenchuk committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=69a80316f7da33e90e1006624466f52af524f1dc tdf#89141: reverted a workaround for getting activity time It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Ah - a bit silly, we should have said we're working on it; we duplicated this & were waiting for testing here: http://cgit.freedesktop.org/libreoffice/core/commit/?h=distro/collabora/cp-4.3&id=b0760a5732b70c42bfdc370a7a019403c2643a8d It seems unlikely that Vasily's proposed fix (to the gtk+ backend) is going to help the KDE use-case, though it looks sensible. Robert - I assume you're using the kde plugin; can you report the output of: $ lsof -p `pidof soffice.bin` | grep vcl Pending confirmation that this indeed fixes the KDE issue, I'd like to leave this one open: we're working on it =) Thanks !
For posterity, the relevant pointers to cause & fixes: - regressed as part of the fix for i#99360 - cause for that was an xcb bug, also reported as * https://bugs.launchpad.net/ubuntu/+source/ekiga/+bug/322310 * https://bugzilla.redhat.com/show_bug.cgi?id=477174 - root cause fix: * http://lists.freedesktop.org/archives/xorg/2009-January/043048.html
(In reply to Michael Meeks from comment #13) > > It seems unlikely that Vasily's proposed fix (to the gtk+ backend) is going > to help the KDE use-case, though it looks sensible. Robert - I assume you're > using the kde plugin; can you report the output of: > > $ lsof -p `pidof soffice.bin` | grep vcl Don't know, what I'm doing, but here it is: -------------- robby@robby:~/Arbeitsfläche/Lotest/LO4362/install/opt/libreoffice4.3/program> lsof -p `pidof soffice.bin` | grep vcl soffice.b 3102 robby mem REG 8,3 854294 4719055 /home/robby/Lotest/LO441/install/opt/libreoffice4.4/program/libvclplug_genlo.so soffice.b 3102 robby mem REG 8,3 760104 4728321 /home/robby/Lotest/LO441/install/opt/libreoffice4.4/program/libvclplug_gtklo.so soffice.b 3102 robby mem REG 8,3 146785 4719056 /home/robby/Lotest/LO441/install/opt/libreoffice4.4/program/libvclplug_svplo.so soffice.b 3102 robby mem REG 8,3 8460637 4719054 /home/robby/Lotest/LO441/install/opt/libreoffice4.4/program/libvcllo.so soffice.b 3102 robby 17r REG 8,3 12850 4727306 /home/robby/Lotest/LO441/install/opt/libreoffice4.4/program/resource/vclde.res --------------- Regards Robert
Hi Robert; how interesting ! you're using the gtk+ plugin / backend while using KDE. That is rather non-intuitive (is that a deliberate choice, do you export SAL_USE_VCLPLUGIN in your environment ?) if so then you will most likely want to have both fixes I think; interesting.
(In reply to Michael Meeks from comment #16) > Hi Robert; how interesting ! you're using the gtk+ plugin / backend while > using KDE. That is rather non-intuitive (is that a deliberate choice, do you > export SAL_USE_VCLPLUGIN in your environment ?) if so then you will most > likely want to have both fixes I think; interesting. Hi Michael, all the stuff I installed for LO. Screenshots for the Base-Handbuch. I have installed xfce for this. When using LO with KDE the scrollbars appear green ... Regards Robert
I just wanted to report back that Vasily's patch fixes the problem for me when using Unity on Ubuntu 14.04 (using the LO GTK+ backend), but as expected, not when using LO with KDE (and the LO KDE backend). When using only the patch from comment 13, the problem is fixed for both, the GTK+ and KDE, backends.
Luboš Luňák committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=67ff4ba5294352b7ed948b196551dea331ee0877 dump ugly hack working around an ancient libxcb bug (tdf#89141) It will be available in 4.5.0. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Both fixes are in master (4.5.0). Problem is not reproducible any more.
Comment #20 > Verified.
Migrating Whiteboard tags to Keywords: (bibisectRequest) [NinjaEdit]