Issue 12701 - Race cond with WM when opening new window
Summary: Race cond with WM when opening new window
Alias: None
Product: ui
Classification: Code
Component: ui (show other issues)
Version: OOo 1.1 Beta
Hardware: PC Linux, all
: P2 Trivial with 3 votes (vote)
Target Milestone: OOo 2.0
Assignee: Joost Andrae
QA Contact: issues@ui
: 12728 (view as issue list)
Depends on:
Reported: 2003-03-26 23:19 UTC by Unknown
Modified: 2004-11-04 14:21 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Note You need to log in before you can comment on or make changes to this issue.
Description Unknown 2003-03-26 23:19:10 UTC
When opening new window or document, with other separated transients such as
"Paragraph Style" of "Cell Style" opened, the windows flashes for several
seconds, raising alternatively one or the other transients, just like a race
cond betwwen OO and the Window Manager.

The problem shows in kde 3.1 and xfwm4 at least.
Comment 1 eric.savary 2003-03-27 16:04:29 UTC
ES->PL: Duplicated on KDE 3.0. We already talked about that.
Comment 2 philipp.lohmann 2003-03-27 17:38:37 UTC
looks ugly
Comment 3 Unknown 2003-03-27 19:27:37 UTC
Defect should be closed. The problem was in the window manager (now

Sorry for the wrong report.

FYI (if that can be of any help for KDE 3.0), the problem is caused by
a wrong focus management in the window manager. OO hides its
transients prior to the main window so the window manager (xfwm4 in
that case) was wrongly assigning the focus back to the main window,
that was showing again, and OO remapped the transients, and so on...
Thus the loop.

Comment 4 philipp.lohmann 2003-03-28 09:04:06 UTC
There was at least one case of XSetInputFocus that OOo did which would
lead to the infinite loop, not only with kwin but with Dtwm and
others. Since this XSetInputFocus was originally for a workaround for
Sawfish i'd like to fix this. After removing this problem there
remains this: if you open a new document while one of the transients
(e.g. stylist) has the focus, the new document ends up beneath the old
one. Might this be the window manager bug you mentioned ?
Comment 5 philipp.lohmann 2003-03-28 09:06:46 UTC
Will at least fix the XSetInputFocus issue.
Comment 6 Unknown 2003-03-30 20:26:42 UTC
I have some additional informations.

The problem comes from OO mapping/unmapping the transients when the
user changes focused window in Open Office.

What happen is that when the user opens a different type of document
(e.g. open a calc doc when having a text document already opened), OO
changes the transients by hiding and showing them (by transients, I
mean windows like "Paragraph Style").

Depending on how the window manager handles focus when a (focused)
window is unmapped, this can lead to an infinite loop. When the
transient window is unmapped, the focus can return to another OO
window that will then hide again the transients and so on.

Unfortunately, I think there is no easy way to handle this (all window
managers may apply different policy for focus management). A way on
achieving the required behaviour could be to set explicitely the focus
(using XSetInputFocus) to a window that is known to stay (must be
mapped and visible for XSetInputFocus to work), grab the server,
perform all the map/unmap windows and then ungrab the server, and set
the focus back to the right OO window.

I think the grab/ungrab of the server is required because, if the
window manager is in "focus follow mouse" mode, the focus may change
as the user moves the mouse during the map/unmap operations.


1) That's not a window manager bug :)
2) The problem doesn't show in metacity because metacity gives focus
back to the window on top of stack instead of the real previously
focused window (like xfwm4 and kde do).

As for point 2), I've changed xfwm4 to act like metacity and indeed,
the problem does not occur. Unfortunately, I don't think that's a good
policy from a user stand point. And again, if the user uses "focus
follow mouse", the problem is not fixed. 

Hope all this makes sense to you :) I'm not sure I'm making myself
very clear!

Comment 7 philipp.lohmann 2003-03-31 08:52:38 UTC
It does make sense, i thought the problem was along this line. I never
felt happy with this map/unmap stuff of stylist and navigator and now
it bites back.
Comment 8 philipp.lohmann 2003-03-31 11:16:19 UTC
pl->mba: I cannot really work against the WM. What should work (and
was the orginal plan AFAIK) would be if you hid the second stylist
when the new document gets its focus (at the same time you show the
new stylist). The better solution would be to have one stylist window
the content of which would be exchanged when switching to another
document, but i don't know if that is feasible for you.
Comment 9 Mathias_Bauer 2003-04-02 07:50:16 UTC
I don't see this as a solution, and I also don't want to do such
changes in sucha short time before a planned release.

This is a problem that appears only in a special situation on a
special platform, so I don't see this as a P3 bug and I also don't see
that we should fix that in the 1.1 version.
Comment 10 Unknown 2003-04-02 17:16:48 UTC
You may choose to ignore that problem, but keep in mind this is not
specific to a given desktop (xfce4 in that case), but it also shows in
kde 3.x and probably a bunch of other DE/WM (I would not consider KDE
as a special desktop case)

In a general comment, I would say that changing window focus on behalf
of the user is not a very good policy (in terms of usability) - Basing
windows map/unmap on focused window is even worse.

Comment 11 Mathias_Bauer 2003-04-02 17:44:33 UTC
I don't ignore it. I only say: it's less severe than many other bugs
that are classified as "P3". And even if it were I a "P3", it wouldn't
be possible to fix it in the 1.1 Beta in a way as proposed by Philip.
That's the reason why I think it should be fixed in the 2.0 version.

In general it's not so easy as one might think after reading Philips'
post. The hiding/unhiding is necessary, because otherwise we end up
with 10 stylists on the screen for 10 open windows. And having only
one Stylist for all windows doesn't work also, because this window is
dockable - that means, we *must* have one per document window.

I agree that we should think about that problem - but I don't see this
in the timeframe of OOo1.1.
Comment 12 Unknown 2003-04-02 19:22:06 UTC

Yes, sorry. I've been a bit too straight :)

What about this: Why not hiding the old windows *after* showing the
new ones ?

That would fix 90% of the problem, because most window manager
automatically focus newly mapped windows, and even in focus follow
mode, there is a chance that the newly created windows will cover the
old ones anyway.

Plus, if the focus is not on a window being unmapped, the window
manager has no reason to change the focus...

Comment 13 eric.savary 2003-04-02 22:00:50 UTC
ES->MBA: my 2cts - user side.
I think you don't work a lot with OOo on Linux isn't it? ;-)
I persoaly get really bored about that every 10 docs (and you knoe I 
open a lot of in one day ;-) ).
It is a really disgusting behaviour (and "broken"!!) which looks like 
a loop if you don't know the way to work around it (simply closing 
the transcient).
So please re-consider your judgment about this issue. Maybe we are a 
litlle be short about the time (target) but it is definitively not a 
This thing really s**ks in the daily work.
Comment 14 eric.savary 2003-04-02 22:02:24 UTC
*** Issue 12728 has been marked as a duplicate of this issue. ***
Comment 15 Joost Andrae 2003-04-11 14:10:11 UTC
start soffice
open file open dialog and multiselect either impress, math or writer
sample documents from office/share/samples/ and load the documents:
--> after loading the documents the application loops and very often
switches the focus

Reproduced within tune01 cws (based on srx644m9 and
vcl07 cws ( on linux on different systems. On windows I
wasn't able to reproduce it. PL ment it really doesn't look good. I
would really like to have this fixed for 1.1. Please think about this.
Changed priority

Regards, Joost
Comment 16 Mathias_Bauer 2004-04-30 15:15:10 UTC
Carsten, we should think about a way how two LayoutManagers can synchronize this
process (of course without hacking it ;-)).
Comment 17 carsten.driesner 2004-05-03 08:50:22 UTC
Comment 18 carsten.driesner 2004-11-04 13:13:55 UTC
Comment 19 carsten.driesner 2004-11-04 13:15:40 UTC
CD->JA: I am not able to reproduce this behavior with a current SRC680 build.
Can you please provide a simple test scenario, so I am able to fix this. As ES
is in vacation you are the only one who has been able to reproduce this.
Comment 20 carsten.driesner 2004-11-04 13:16:23 UTC
CD: Set to works for me.
Comment 21 Joost Andrae 2004-11-04 14:21:27 UTC
JA: using a current src680 master (m60) I wasn't able to reproduce this again.
The repaint behavior changed between srx645 codebase (1.1.x) and src680
codebase. Closing as worksforme.