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
Created attachment 114243 [details] x11vis.org trace of the libreoffice/i3 interaction
Created attachment 114244 [details] x11vis.org trace of the libreoffice/i3 interaction (2)
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.
*** Bug 90381 has been marked as a duplicate of this bug. ***
*** Bug 90718 has been marked as a duplicate of this bug. ***
This needs to be high priority. Possibly the same as bug 90705 (KDE).
*** Bug 90705 has been marked as a duplicate of this bug. ***
Serious enough issue along with multiple dupes to throw on the mab list.
*** Bug 91171 has been marked as a duplicate of this bug. ***
@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.
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
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.
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
ok, seems to work ok under windows too, so looking good I think
https://gerrit.libreoffice.org/15910 for 4-4
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.
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.
*** Bug 90759 has been marked as a duplicate of this bug. ***
*** Bug 90635 has been marked as a duplicate of this bug. ***
Verified as fixed by an i3 dev in this: https://github.com/i3/i3/issues/1448
*** Bug 86198 has been marked as a duplicate of this bug. ***