Apache OpenOffice (AOO) Bugzilla – Issue 12701
Race cond with WM when opening new window
Last modified: 2004-11-04 14:21:27 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.
ES->PL: Duplicated on KDE 3.0. We already talked about that.
looks ugly
Defect should be closed. The problem was in the window manager (now fixed). 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.
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 ?
Will at least fix the XSetInputFocus issue.
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. Therefore, 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! Cheers, Olivier.
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.
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.
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.
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. Cheers, Olivier.
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.
Mathias, 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... Cheers, Olivier.
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 P4. This thing really s**ks in the daily work.
*** Issue 12728 has been marked as a duplicate of this issue. ***
JA->MBA: 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 unxlngi5.pro) and vcl07 cws (unxlngi4.pro) 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
Carsten, we should think about a way how two LayoutManagers can synchronize this process (of course without hacking it ;-)).
.
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.
CD: Set to works for me.
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.