Autoraise: how to prevent?

[pfortin]

The answer is probably too obvious for me to find... but how do I prevent OOo from auto-raising its windows?

I am running OOo 2.3.1 on the latest Mandriva Linux with KDE which is set to auto-focus to the window under the mouse (not auto-raise which I hate). Yet, OOo auto-raises its windows when I accidentally move the mouse outside the current window I'm working in. I've had this issue for a long time; but today it's really getting to me...

Thanks,
Pierre

[Hagar Delest]

It may be a distro integration issue. You could try with the official version (from OOo web site) if you can reproduce that.

NB: moved the thread to the Linux forum.

[acknak]

It's in the official builds as well. I assume it's just the way OOo works.

In many situations, the problem makes OOo almost unusable, and absolutely ridiculous, with the way it insists on putting the wrong window on top (e.g. with a help window open).

Having a look just now, I find:
Issue 17719: Paragraph style window (and similar) steals windows focus. (Window manager integration?)
Issue 17810: window is auto-raised whenever focus is received
Issue 19489: Automatically rising the focus window is extremely annoying

Issue 17810 is not active (marked as a dup to 17719), but it has a long discussion. I'm not sure what the difference is between 17719 and 19489.

You can register there and add a comment or votes to whichever you think is appropriate.

If you take time to read those, and it seems clear to you, please post a summary here!

[kingfisher]

I don't enjoy such fine distinctions as an Xfce user. My recollection is that you need to set a mouse click to the auto raise function. It sounds to me as though your settings for raising and focussing are both set to mouse hover.

[acknak]

Could be, but it's definitely not the case for Gnome. I chose the WM policy as focus-follows-mouse with no auto-raise, and all other apps follow that; only OOo raises windows without my asking. It's a big nuisance for me.

[Hagar Delest]

WM policy as focus-follows-mouse with no auto-raise, and all other apps follow that

Works fine for me with Gnome 2.14.1, Ubuntu Dapper and OOo 2.3.1. Even when I type in OOo after the mouse left another windows above, Writer is not raised.

[acknak]

Try it with two or more document windows and a couple of floating toolbars or windows like the Stylist or Find & Replace. Now move the cursor over the document windows: OOo raises (or asks the WM to raise) the floating windows for whichever document window has the focus. Ok so far. Now open a help window and try moving the cursor around. It quickly becomes unusable--if not comical--the way various windows pop in and out, covering the very help window I'm trying to read.

With multiple document windows, it's not difficult to get into a situation where a floating window like the Stylist is completely impossible to use because, to get to it, the mouse cursor has to pass over a different document window. The only way to recover it is to move it's document window to touch it.

I should also say that I typically use a magnified viewport of 800x600 on a virtual screen of 1280x1024, just to give my old eyeballs a break. In order to move the viewport around the larger screen, I have to move the mouse "outside" the viewport. This often causes the focus to change as well, and in ways that I can't predict because I'm moving the mouse into parts of the virtual screen that I can't see. With OOo this is like playing Russian roulette because of the windows that raise automatically when a document window receives focus. It's more complicated to describe than it is to use. I find it immensely useful and it works perfectly for everything except OOo, because OOo is the only app that automatically raises windows.

Yes, I could mitigate the problem somewhat by docking all the toolbars and floating windows, but that's just not my cup of tea. I really didn't mean to complain, as I admit mine is an unusual situation and I could take steps to lessen the problem, but I wanted the OP to know he's not the only one who sees this.

[Hagar Delest]

Well, I undocked the Stylist, the Navigator, the Drawing toolbar, opened a spreadsheet, a text document and the help window. I agree it's slightly more messy because when the cursor moves above a document window, the undocked toolbars/panels pop up; but disappear as soon as the mouse comes back on the help window.

[acknak]

Interesting. i guess it could be a WM "feature". Metacity is surely weird enough; but as I said, OOo is the only app that I have any trouble with. Gimp opens a hundred windows, but it never does this:

Here's another one that's a lot of fun. In Calc, I bring up the function wizard to work on a formula. I click the "Help" button on the function wizard. The Help window opens, on top of the function wizard as it should. Now, leave help open, bring the document & wizard back to the top and click "Help" again. Now help pops up, and immediately goes away, under the Calc document window. I wish I could make a video, it's hilarious (unless you're trying to work). I have two text documents and a spreadsheet open, and the windows fly up, down and around like a house of cards in a hurricane.

Both the Fedora OOo build and the OO.org build do exactly the same thing, so I assume it's something in the OOo code that causes it--or at least something that interacts badly with the WM. And I just tried it under KDE: same thing. So it's not just Gnome/Metacity.

[pfortin]

Cool... so it's not just me... I use KDE with focus-strictly-under-mouse. As others note, it's aggravating that only OOo acts as though I'd set auto-raise which I hate... click-to-raise just to be able to input something is so Windows (lame)... I love just moving the mouse and having my windows stay put, yet accept input...

Also, while OOo may come with my distro (Mdv 2008.0), I always install OOo separately.

[pfortin]

Forgot to mention the worst part... for example, right now, I'm working on a writer doc with a table... so the undocked "Table" toolbar (UT) injects itself without my asking... just move the mouse over this UT and all hell breaks loose... The mouse flashes like crazy, switching rapidly between I-beam and pointer; the main writer window and the UT alternate focus at very high speed, and the UT, sitting partly off the main writer window just has a fit trying to decide if it should display or not, just like happens when moving the mouse in and out of the main window. Definitely would require a video to show...

Actually, when the mouse is over one of these UTs, it appears OOo considers the mouse is no longer within the x1,y1/x2,y2 of the main window, calls the lost focus function which hides the UT. Then, when the UT is hidden, the main window goes "OH... I just got mouse focus!" and unhides the UT... can you say 'oscillation'?

[acknak]

Weird. I don't see anything like that on Fedora, either with the distro packages or the OO.org packages, on either Gnome or KDE. I don't think it's OOo's fault.

[mpolo]

The problem also exists in Fedora. To duplicate it, put your windows on "Focus follows cursor" but without "Automatically raise focused windows". [I'm using Compiz on top of XFCE, by the way.]

Normal behavior would be that windows gain focus when you mouse over them, but don't raise themselves. However, OpenOffice.org (and by extension LibreOffice.org) have chosen to ignore the settings in the windowing manager and raise any window that gets focus. That means that I often am forced to minimize windows because to get my cursor over to a dialog box, I have to cross in front of another window, and that raises the window, removing the dialog box I was trying to reach.

It is an extremely annoying behavior. I can hardly use a computer that doesn't have "Focus follows mouse cursor" -- it's one of those "once you use it, you will never go back" features. It's almost enough to make me look for an alternative to OpenOffice, since it seems that no one wants to admit that the problem exists, or if it is admitted, no one is interested in fixing it.