Issue 19489

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.