Apache OpenOffice (AOO) Bugzilla – Issue 19489
Automatically rising the focus window is extremely annoying
Last modified: 2013-02-07 22:16:00 UTC
I might have not yet found the correct configuration option to switch this behavior of which seems to have been introduced with v. 1.1RC3 or RC4: The application window which has the input focus is put into the foreground automaticly. With a window manager setting the focus according to the position of the mouse cursor this leads to very annoyingly flickering screen rearangements. Environment: KDE 3.1.3, SuSE Linux 8.2 Best regards, Joachim
I recently was in a situation that OpenOffice announced to restore two files which were _not_ damaged by a crash. The confirmation popups appeared several times within that program run basically preventing any other work. After accepting/cancelling restoration the application windows were no longer raised automatically. This seems to have repaired the silly behavior somehow. After restarting OO everything looked and looks fine. The installation had been done freshly from the distribution package as a shared installation. The personal installation procedure showed no differences from the RC3 installation.
Here is more information. The windows get raised along with the stylist windows: If two documents are open and the corresponding stylist windows are active moving the mouse between the two document windows does not only display the associated stylist window but raises the document window as well. This affects all windows which have a corresponding stylist window. It looks like the stylist window pulling the document window into front.
This behaviour has always been there. If the Stylist, or Navigator, or any other OOo dialog is activated, the window that "owns" the dialog will be raised automatically when focus is shifted. This should be a "feature request" because you are simply saying that you prefer a different behaviour. I will change the issue type to "feature request". More importantly, this is not a major bug, it does not deserve the P2 status. I will set the priority level to P5 (I have half a mind to make that P4). This is unlikely to be changed right away. I am setting the target milestone to 2.0. I will confirm this issue and set it to "new". Note: If I have misinterpreted the nature of your issue it is important that you write back to say so. If I have misqualified the severity of this issue all of these values can ge changed. If you feel that this is important, vote for this issue and ask the list to vote for this issue.
SBA: Reassigned to Bettina Haberer from the User Experience team for consideration.
Hi, I am a bit confused with the actions (not) taken. I feel that asking for removing an annoying and confusing behavior is not something that should be regarded as a feature request. So let me argue a little bit: (a) It _is_ extremely annoying to have the complete screen controlled by a small helper window. From a user´s point of view the main application window -- or the document window in this context -- should be the controlling one. (b) A feature is an additional functionality as seen by the user. Even if some basic internal control flow needs to be extended to stop the described behavior this extension is not an extension to user functions. So this case should at least be classified as an enhancement. (c) I understand that the dialog windows are something in between top-level application windows and modal windows. In OO 1.1 these windows look like real top-level windows: they can be dragged around on the screen, and they do not disappear when an option is selected as was the case with these dialogs in OO 1.0. So they are merely a free floating extension to the toolbar. All the tools on the toolbar control certain attributes of a document. None of the buttons leads to a rearrangement of the window stack when touched by the mouse cursor. So please make these dialog windows less modal: Let the document window bring up the dialog along with itself, and not the other way around. (d) Looking at all the wonderful features and the overall excellent usability of your product I would like to suggest raising the priority of this issue in order to have it considered at all. This is to say that you should not taint OpenOffice with such a stupid thing. I understand that most of the users will use OO in a Windows environment where you can hardly separate the position of a window in the stack from the keyboard focus. Under Linux/UNIX you have a choice. So let's not take away this choice by forcing everybody to the stupid MS idea of window management. (e) I feel I have to insist in (= kindly ask for) processing this issue. Having worked as a programmer, quality and usability engineer for more than 20 years I am convinced it is at least priority 3 and it is a bug. I look forward to testing the fix for this issue;-) Best regards, Joachim
This is a FEATURE only if you use "click to focus" window management. If you use "focus follows mouse" or "focus under mouse" this is a HORRIBLE BUG!!! Every time the cursor passes over any window of an OOo document that was not the last one raised, it pops to the foreground. This means that it is impossible to maintain control of which window is on top if more than one OOo document is open on the desktop. If "click to focus" is used, the window is expected to be raised at the same time also. The OOo behavior is not annoying in this case. In "focus under mouse" mode, as the cursor slides across the desktop, each window gets focus in turn. An OOo document is sure to pop up whether I want it or not. No window should be raised unless I click on the border! This new behavior ruins the function of "focus under mouse" Please, Please fix this. I would rather go back to 1.0.3.1 than use 1.1 in this condition. It is not worth the aggravation. Best Regards, Bill
Hello Philipp, according the decribed behaviour I consider this as a defect.
I completely agree, but that's a "feature" of the window manager. There is no way to tell the WM "don't raise the window i'm transient for unless i get clicked". We cannot do anything against it.
closing
Hi, I think this bug can be fixed. Now that we agree upon it as being a defect it should be removed. I am not familiar with the window relationships in OOo, but I would like to suggest breaking the relationship of the document and tool windows. Why do the tool windows need to be coupled to the documents? When I change the background color of an element this action does not call for multiple tool windows, one for each document opened. Wouldn't it help to redirect the callbacks (or the document objects passed along) of the tool window to the document having the input focus? I am pretty sure that there is a way around that. Please think about it. My X11 programming experience tells me this could be done differently. Best regards, Joachim Schnitter
The way it is currently the tool windows need to be transient for the document as to not vanish behind the document - which would IMHO vastly more annoying than the current behaviour. As to what you suggest that e.g. multiple stylists all share the same system window: i suggested that, too, but the framework lead said it was not be implementable in a reasonable timeframe with reasonable effort. I'll reassign this issue to him so he can explain in more depth (or perhaps you can convince him :-) ).
If the alternative is either to get rid of this "annoying" behavior or to keep the ability to have tool windows in front of the document window (and not behind it), I would opt for the second option. The number of former windows users that will be confused from vanishing tool windows will exceed the number of experienced Linux/Solaris users that can handle a focus following the mouse cursor bei far. Matthias, what's your opinion about that? Is it more important to have tool windows always in front of their document window or is it more important to support window managers that allow the focus to follow the mouse cursor? We can't have both, because only Windows is able to open the tool windows without setting the focus into it (and exactly that's what we are doing on that platform), according to PL this is only a planned feature for other window managers. A third option would be to make it configurable, but we should be honest that this is only a workaround. I also must say that this would force us to invest a considerable effort to implement shared tool windows, and I only want to implement this if we see a real important requirement to do so.
Hi, I understand that this is not an easy issue to deal with. Perhaps the solution with separated tool windows is not the best approach. Although I am completely stuck to Linux, regarding these little thingies I definitely appreciate MS Office's way to handle them. In the hope there are no silly patents which prevent other software vendors from using pull-down menus with icons I would like to suggest looking at the big competitor, or, as attributed to Stravinsky: "Lesser artists borrow, greater artists steal". So being one of the greater artists would require: - replacing the tool windows by pull-down/combo boxes - keeping the most recently selected tool option (color, formatting etc.) as a default for reuse when formatting the next element The latter point addresses another annoying detail of the tool windows. If I want to format (e.g. color) several document elements the same way, I have look up the correct option/icon and click on it. This is so different from the MS Office way, where I simply click on the combo box button to apply the last settings to another element. It seems nobody at Star Division/Sun uses the four Sun corporate colors frequently with OOo. Having to look up the correct color in the tool window for every element to be colored is no real fun. Thanks for dealing with these problems. I am sure you find a working solution. As an intermediate workaround it might help to address this issue in the FAQ and in the product documentation. Regards, Joachim
Matthias, what's your opinion about the two alternatives?
changed target to Office later
This bug is affecting me too so I just wanted to add my comments. I also use KDE with focus follows mouse. If I have two editor windows open, In the left window, I open the Find&Replace dialog. I move this dialog over the top of the right window so that it doesn't obscure the text I'm searching in. Now, when I move the mouse back to the left window, it passes over the right window and my "Find & Replace" dialog disappears below the right window. The only way to get at the "Find & Replace" dialog is to minimise the right window. Very annoying. This isn't a Window manager issue: no other applications do this. If some users want their windows raised on focus, they should configure the window manager to do that. It is also annoying if I want to cut and paste text that is visible from a partially obscured window. I don't want the window raised.
Yes, this is very serious bad behavior of OOo when "focus follows mouse/hover" is activated in the WM instead of "focus follows click". Here is a funny thing to try in order to prove just how serious this problem is: 0) Use "focus follows mouse/hover" in your WM (in my case, KDE). 1) Open up the Navigator or the Stylist to a document in OOoWriter. 2) Move the main document window away from the helper window (this happens commonly when you want to juggle with more than one document). 3) Now try to get to your helper window. Haha! See? Since the main "parent" window loses focus, the little helper window disappears the moment the cursor leaves the parent! This means that you have first reposition the parent so that it overlaps with the helper before you can reach it again. Apart from this being a genuine no-no rendering OOo unworkable (it's the app serving the user, not the other way around, remember?), I second strongly the notion that this needs to be taken care of appropriately. Also, I would like to take the opportunity of this occasion to point out just how much easier it was to work with multiple documents back in StarOffice 5.x where you could have them side by side vertically or horizontally within the integrated desktop window. Working with OOo has become more difficult ever since all this "separate windows" paradigm gave rise to this focus hopping spree.
What about making the Navigator and Stylist windows being some that exist only per-session, not per document? Gimp has this feature since a long time now, eg. in its layer dialogue. At the top of that window, you find a drop-down menu that lists the open images... And while we are at it, please also take a look at the new file selector dialogue in Gimp 2.2. 8-))
*** Issue 60935 has been marked as a duplicate of this issue. ***
I don't understand why openoffice plays with focus at all. It is a window manager policy issue. The comment from mba says that we should cater to the windows user in the linux build of OO. The windows user will be using the default window manager that comes with their "user-friendly" distribution of linux, which will most likely have the appropriate policy decisions made by the window manager, where such decisions belong. Those of us who have used the policy of focus follows mouse, for the past 8 years, do not appreciate one application out of our choice of a dozen used in daily life, playing differently to everything else, and deciding policy that does not belong to it. Please test this with, say, fvwm in "focus follows mouse, does not raise" mode, and see how every single dialog that it opens ends up flickering the focus. Just dragging my mouse over an OO frame with a popup is enough to bring the whole app into the foreground, obscuring what I was working on below it. Other apps that do fiddle on the edges with focus (say, acroread bringing up a small dialog for find) manage to put focus on the temporary dialog without bringing the whole app to the foreground, flickering, or otherwise doing anything else silly with focus or z-order. Just what is OO doing that ends up being so different? Thanks for listening.
I fully agree with tconnors and would like to add that not only no other application I know does this, but also that several of them are available on Windows, too, and don't seem to scare the hell out of those Window users. Like eg the Mozilla stuff, or The Gimp. They all subject to WM policy, only OOo sticks out.
*** Issue 82326 has been marked as a duplicate of this issue. ***
Additionally, this comment from mba, confuses me: "We can't have both, because only Windows is able to open the tool windows without setting the focus into it (and exactly that's what we are doing on that platform), according to PL this is only a planned feature for other window managers." That's normal behaviour in focus follows mouse window managers and presumably other window managers if you don't try to do anything tricky at all (a lot of toolkits insist on doing tricky things by default - you have to find a way of disabling any tricky behaviour within the toolkit). Most dialogs up until recently opened without focus applied to them. Some programs (eg, galeon from the good old gtk1 days) were smart enough that if the dialog was intended to be modal, the dialog was opened without window focus, but the main window still sent the keystrokes into the dialog. Behaviour like this would seemingly solve all of your perceived problems, no?
I am no longer officially active on OOo. Please take over.
This issue is still around, and OO still becomes nearly unusable with focus- follows-mouse and multiple document windows. I cannot stress enough how intensely frustrating this bug is. I also have to disagree with the P5 priority. For click-to-focus, this may be a non-issue, but for mouse-focus users, it it one step shy of a complete show stopper. The only workaround I've found at all is to actually keep a search/replace dialog open (and over top of the associated window) at all times for pretty much every document I'm working on. That way, every OO window that gets focus has a "local" dialog appear when it gains focus as I mouseover. It's difficult to understand why this would be a problem to fix. As many have pointed out, there are innumerable apps that use multiple windows with non-modal dialogs that don't do anything like this. (gnumeric, gimp, gnome-terminal, just to name a few). *Please* consider fixing this sooner rather than later.
Using kde4 with Window Behaviour Focus : Focus Strictly Under Mouse Start OpenOffice Writer with a new a document Instance (1) Insert a table, OOo will pop up a floating window with table buttons The pop-up steals the mouse focus and flickers when the mouse is over the floating window. It's is difficult to move this floating window. It is impossible to close this window, as the mouse cannot be moved over the 'x' button to close it. Instance (2) Create a numerated list. OOo will pop up a floating window with 'list' button helps. The pop-up steals the mouse focus and flickers when the mouse is over the floating window. It's is difficult to move this floating window. It is impossible to close this window, as the mouse cannot be moved over the 'x' button to close it. Often OOo steals the mouse focus and you cannot type or click in OOo. Turning off 'Focus Follows mouse' alleviates the issue. Reproducible: Always
For one reason or another, this bug (and it really is a bug, not a misfeature, as far as I am concerned) has really started affecting me badly since upgrading to 3.2.0 (official build -- up to now I had used Fedora builds, but needed the docx compatibility sooner rather than later -- you can guess that I am going back to a Fedora build as soon as feasible). Now it is practically impossible to work on two documents at once, as even slightly "grazing" the window of another document with the mouse steals focus and loses the window I was actually working on. It is really a show-stopper for users of "focus follows mouse". Could we at least have a preference of "don't raise on focus" or relegate this all back to the window manager, where it really belongs?
This problem continues even with the Fedora builds of OpenOffice 3.2.0. It seems to be linked to the "Styles and Formatting" dialog. If that dialog is open, then just passing the mouse from one side to the other pops all the OOo windows into the foreground, thus frustrating any attempts to click on smaller dialogs. This impacts productivity in all programs on the computer, not just OOo, as long as OOo is open. Maybe a relatively quick fix: could there be an option of docking the "Styles and Formatting" window somewhere (a toolbar or sidebar, for instance)? That might be enough to solve the problem without affecting this "feature" for persons using other mouse focus paradigms.