Bug 90155 - (i3wm, Gala [elementary]) Not possible to open color dropdown
Summary: (i3wm, Gala [elementary]) Not possible to open color dropdown
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.4.1.2 release
Hardware: x86-64 (AMD64) Linux (All)
: highest major
Assignee: Caolán McNamara
URL:
Whiteboard: target:5.1.0 target:4.4.4 target:5.0....
Keywords:
: 86198 90381 90635 90705 90718 90759 91171 (view as bug list)
Depends on:
Blocks: mab4.4
  Show dependency treegraph
 
Reported: 2015-03-22 10:14 UTC by spippi
Modified: 2016-10-25 19:24 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:


Attachments
x11vis.org trace of the libreoffice/i3 interaction (423.09 KB, image/png)
2015-03-22 11:43 UTC, Michael Stapelberg
Details
x11vis.org trace of the libreoffice/i3 interaction (2) (611.20 KB, image/png)
2015-03-22 11:43 UTC, Michael Stapelberg
Details
likely to work under X (1016 bytes, patch)
2015-05-22 15:50 UTC, Caolán McNamara
Details

Note You need to log in before you can comment on or make changes to this bug.
Description spippi 2015-03-22 10:14:11 UTC
In libreoffice writer if i want select a color characters or background, the window of the colors close immediately.

i use archlinux with WM i3,  i try with another pc and i3 same problem, same pc and gnome work perfectly.

I had open a issue in github (https://github.com/i3/i3/issues/1448) and user advice to open a bug report here, you can find other info in link github of issue

thanks
Comment 1 Michael Stapelberg 2015-03-22 11:43:21 UTC
Created attachment 114243 [details]
x11vis.org trace of the libreoffice/i3 interaction
Comment 2 Michael Stapelberg 2015-03-22 11:43:50 UTC
Created attachment 114244 [details]
x11vis.org trace of the libreoffice/i3 interaction (2)
Comment 3 Michael Stapelberg 2015-03-22 11:45:03 UTC
I’m the main developer of i3 and spent a bit of time debugging this issue.

By using the following patch for i3, you can reliable reproduce the problem:

diff --git i/src/handlers.c w/src/handlers.c
index 0cd397f..b96433b 100644
--- i/src/handlers.c
+++ w/src/handlers.c
@@ -458,6 +458,7 @@ static void handle_screen_change(xcb_generic_event_t *e) {
  */
 static void handle_unmap_notify_event(xcb_unmap_notify_event_t *event) {
     DLOG("UnmapNotify for 0x%08x (received from 0x%08x), serial %d\n", event->window, event->event, event->sequence);
+    sleep(1);
     xcb_get_input_focus_cookie_t cookie;
     Con *con = con_by_window_id(event->window);
     if (con == NULL) {

Here are a couple of interesting observations:

1) https://bugs.documentfoundation.org/attachment.cgi?id=114243 shows libreoffice mapping a window and then unmapping it, without waiting for the window manager to actually map the window. I.e., libreoffice is not waiting for the MapNotify event.

2) https://bugs.documentfoundation.org/attachment.cgi?id=114244 shows that libreoffice is then sending a MapRequest for that same window (see the MapWindow w_56 call in the very last buffer), without having waited for the window manager to confirm the previous UnmapWindow by setting the WM_STATE to WithDrawn.

I think both of this is unsafe and prone to race-conditions at the very least. If I read ICCCM section 4.1.4 correctly (see http://tronche.com/gui/x/icccm/sec-4.html#s-4.1.4), what libreoffice does in (2) is even a spec violation:

> When a client withdraws a window, the window manager will then update or remove the WM_STATE property as described in section 4.1.3.1. Clients that want to re-use a client window (e.g. by mapping it again or reparenting it elsewhere) after withdrawing it must wait for the withdrawal to be complete before proceeding. The preferred method for doing this is for clients to wait for the window manager to update or remove the WM_STATE property.

Here are my suggestions on how to fix this issue:

1) For showing the tooltip window, ideally you would never need to call XWithdrawWindow() at all, and just map it once at the final position.

2) If that’s infeasible for some reason, please wait for the MapNotify event before Unmapping windows.

3) Regardless of suggestion (1) and (2), never re-use a window before you got the WM_STATE change from the window manager.

Thanks.
Comment 4 Adolfo Jayme 2015-03-31 23:02:52 UTC
*** Bug 90381 has been marked as a duplicate of this bug. ***
Comment 5 Buovjaga 2015-04-25 11:09:52 UTC
*** Bug 90718 has been marked as a duplicate of this bug. ***
Comment 6 Buovjaga 2015-04-25 11:40:04 UTC
This needs to be high priority. Possibly the same as bug 90705 (KDE).
Comment 7 Adolfo Jayme 2015-04-29 15:37:19 UTC
*** Bug 90705 has been marked as a duplicate of this bug. ***
Comment 8 Joel Madero 2015-04-29 15:43:37 UTC
Serious enough issue along with multiple dupes to throw on the mab list.
Comment 9 Adolfo Jayme 2015-05-09 16:31:10 UTC
*** Bug 91171 has been marked as a duplicate of this bug. ***
Comment 10 Joel Madero 2015-05-11 20:51:29 UTC
@spippi - please be more careful about reading instructions.

Version field explicitly says "earliest affected) also when you update the version to a newer version there is a big warning explaining why this should rarely (if ever) be done.

Thanks

Reverting change.
Comment 11 Caolán McNamara 2015-05-22 15:50:39 UTC
Created attachment 115836 [details]
likely to work under X

this is a bit of a cross-platform rats nest unfortunately. I'd prefer to start hidden and not have this show->hidden->show foo. Which the attachment would like fix for us, but the undo/redo popups then to awry under windows
Comment 12 Commit Notification 2015-05-25 09:41:57 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=c4bae028efbd32c8938c3a6051d58c1f202d5b8a

Resolves: tdf#90155 don't hide+show window before initial show completes

It will be available in 5.0.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.
Comment 13 Caolán McNamara 2015-05-25 09:57:35 UTC
I'll give this a go. The analysis above suggests the problem is mapping, unmapping and re-mapping without waiting for WM responses inbetween.

At the level we're working at we're talking through gtk for this. I want a nice minimally invasive fix that we can backport. So lets try this, and check the windows build when it comes available in master to ensure that the "undo" dropdown appears at the right place on screen before backporting
Comment 14 Caolán McNamara 2015-05-26 13:28:17 UTC
ok, seems to work ok under windows too, so looking good I think
Comment 15 Caolán McNamara 2015-05-26 13:35:48 UTC
https://gerrit.libreoffice.org/15910 for 4-4
Comment 16 Commit Notification 2015-05-26 13:53:59 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-4":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=8e3d5f7ed230c07f3f68d4b53edc2c285b04b84d&h=libreoffice-4-4

Resolves: tdf#90155 don't hide+show window before initial show completes

It will be available in 4.4.4.

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.
Comment 17 Commit Notification 2015-05-26 13:57:32 UTC
Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-5-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=abc4d0c705095582cb4a983180e73faef0d913c8&h=libreoffice-5-0

Resolves: tdf#90155 don't hide+show window before initial show completes

It will be available in 5.0.0.0.beta2.

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.
Comment 18 Katarina Behrens (CIB) 2015-05-27 09:02:08 UTC
*** Bug 90759 has been marked as a duplicate of this bug. ***
Comment 19 Katarina Behrens (CIB) 2015-05-27 09:03:47 UTC
*** Bug 90635 has been marked as a duplicate of this bug. ***
Comment 20 Buovjaga 2015-05-27 09:45:06 UTC
Verified as fixed by an i3 dev in this: https://github.com/i3/i3/issues/1448
Comment 21 Caolán McNamara 2015-06-18 10:05:23 UTC
*** Bug 86198 has been marked as a duplicate of this bug. ***