Issue 99971

Summary: New file not in front window
Product: General Reporter: dykim6 <dykim>
Component: codeAssignee: thorsten.martens
Status: CLOSED FIXED QA Contact: issues@framework <issues>
Severity: Trivial    
Priority: P2 CC: avagula, carsten.driesner, cno, ericb, gbpacheco, issues, jbf.faure, kpalagin, lode.leroy, Mathias_Bauer, mikhail.voytenko, nesshof,, pet.ebe, robbin.knapp, thomas.lendo, tml
Version: OOO310m9Keywords: oooqa, usability
Target Milestone: OOo 3.2   
Hardware: All   
OS: All   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 99999    

Description dykim6 2009-03-06 14:50:05 UTC
When you open a new file in an application(write, impress, etc.) that already
has some files open on, the new file won't pop up in the front window. Rather,
the already open older file stays in front and the new files is hidden behind in
a backside window.

This is frustrating. Even though you tried to open a file, you keep waiting for
the file to pop up, in vain. Only when you extra click on the Window menu, then
you realize the new file is in fact up, yet in a background hidden window.

This apparently should be a bug.
Comment 1 Olaf Felka 2009-03-06 15:11:22 UTC
adjusting settings
Comment 2 avagula 2009-06-05 12:33:20 UTC
The same in Windows Vista and 7, new windows are opening in background. 
Comment 3 tml 2009-06-05 12:34:57 UTC
Happens also on XP SP3.
Comment 4 avagula 2009-06-05 12:38:59 UTC
Its present in 3.1 and several platforms/OS
Comment 5 Olaf Felka 2009-06-05 13:14:29 UTC
Resetting version info. It's interesting in which version this has been found.
If it hasn't been fixed we can expect that it is present in the current version.
Comment 6 Mathias_Bauer 2009-06-05 14:10:27 UTC
As discussed already, this is not a bug, OOo just behaves as the system expects
it to behave. It is good common behavior to never actively steel the focus but
wait until the system transfers it to your windows. If the system doesn't do it,
it obviously does not want you to get it. 

We already agreed that we could add an option "ignore system focus handling,
always grab the focus when opening a window". To make clear that this isn't a
bug, I changed the type to "ENHANCEMENT".

But IIRC this is a duplicate anyway. Happy searching. :-)
Comment 7 tml 2009-06-05 14:57:08 UTC
Claiming this is good behaviour is absurd. The user doesn't know the technical
detail that there is actually just one OOo process running that handles all
documents that are simultaneously open. Note that in the Task Manager's
"Applications" pane, each document open in the same OOo process shows up separately.

Surely users expect that when opening a document from Explorer (or its
equivalent on other platforms), a window opens editing the document, and that
this window becomes the active one, is on top of other windows in the current
Z-order to the extent possible, has the keyboard focus, etc. Why should it be
different if another document already happens to be open in OOo?

Also note that at least on Windows the behaviour when opening a second (third,
etc) document is not consistent. Depening on how the user has happened to open
and close documents in the running OOo instance before, and how he has happened
to switch to other windows like Explorer ones, opening a new doc from Explorer
in OOo will or will not make the window for the new document active and on the top.

A corresponding bug report in the Novell bugzilla also brings up the case when a
subsequent document is of a type that needs the user to complete some import
dialog before the document can be loaded. (Like for instance a .csv document.)
That import dialog might be completely hidden. Unlike the case of a document
that loads and opens right away (even if not on the top and not active), the
import dialog does not get any separate taskbar entry. The title for the icon in
the Alt-Tab task switcher for one of the already open documents does change to
"Text import [foo.csv]", though, but for users who don't know or don't like to
use Alt-Tab but just are used to click on the taskbar, that doesn't help, the
dialog window is completely hidden.
Comment 8 Mathias_Bauer 2009-06-05 18:43:53 UTC
I didn't say that it's "good" behavior, I said it's what the platform should
handle. We introduced that behavior due to complaints from users of the Unix
platforms that always grabbing the focus is against the platform rules. It's up
to the window manager passing the focus to a window or not passing it.
Applications must not steal focus.

I agree that this can be confusing for users, that's why I mentioned that we
already discussed and agreed that an option might be fine (with whatever
default). But it's clearly not a defect as we just are good citizens on the
platform we are using. But that's a quarrel about words.
Comment 9 robbk 2009-06-08 06:17:16 UTC
I can't say whether this is good behavior a defect, but it's different behavior
from any Windows application I know of. That's part of the reason it's so
frustrating. I have no idea of Unix behavior, nor do our users. For our users it
is most definitely a defect, and I'm the one they complain to.
We had this problem in version 3.0 already, but only in the Novell edition, not
in the vanilla edition. I tested both. That's why I reported a bug with Novell,
which I assume is the one tml mentioned here. We still have this problem in 3.1
Novell edition; I haven't tested 3.1 vanilla edition.
The others who have discussed this issue please consider voting for it.
Comment 10 avagula 2009-06-08 07:09:29 UTC
Its present also in vanilla 3.1. OK, I could understand this (maybe) when we
talk about new document windows, but when I doubleclick on the quickstarter, the
Templates and Documents dialog also opens in background... No one wouldnt open
this dialog when he dont want to use it.
Comment 11 Mathias_Bauer 2009-06-08 07:42:30 UTC
No reason to convince me - I agree that from a users point of view following the
UI guidelines is confusing here, so we should have an option to change that
(maybe even change it by default).

I just wanted to point out why it is as it is and that this is not a usual bug,
but a problem resulting from an unfortunate combination of UI guideline (don't
steel focus) and the SDI window model of OOo.
Comment 12 dykim6 2009-06-08 08:29:27 UTC
I support the arguments of MBA.

As a user, I won't care how things are implemented inside. I just want a
common-sense behavior of any software.

Whenever I open a file, I'd surely expect it to be on the top of the
screen/window; independently of how many previous files of the same type have
been already open.

Also, I also have been quite often embarrassed that warning dialog box was
hidden in the background. This shouldn't be.
Comment 13 Mathias_Bauer 2009-06-08 09:51:49 UTC
Here just a few issues as a reference why we remove the "focus stealing" in OOo:

issue 62756
issue 49426
issue 19976

There have been some more discussions on several mailing lists, without
repeating it in total the result just was that the best possible implementation
is not to steal the focus at any time and always wait until the OS assigns the
focus. In fact that also fixed a lot of other problems we had in the past.

I hope you can see that there is no simple solution for the problem. How can we
prevent the obviously existing user confusion without destroying e.g. the
feature that the focus is where the mouse is? We thought that the best way is to
always let the OS decide. So IMHO if the current behavior is a bug, it is a bug
of the OS. But I assume that nobody will care about that. ;-)

The best compromise I can imagine is the following:
By default, always grab the focus immediately after the window has been shown,
but never again at any time later. Additionally we need an option to switch that
off and return to the current behavior.

I will try to find a way to discuss that somewhere else to reach a broader
audience. This is not only a UX problem (as it is clear that the current
behavior is unfortunate), it's more a system integration problem.
Comment 14 tml 2009-06-09 13:19:40 UTC
Reading those other bug reports I understand that this is a quite complex issue.

I wonder how other similar apps that use a single instance handle this. Hmm, I
guess one nice example to check would be Firefox. As far as I can see, on
Windows double-clicking on a .html file actually does start a new instance of
Firefox with the command line "C:\Program Files\Mozilla Firefox\firefox.exe"
-requestPending -osint -url "%1" and just like OOo, that instance then (in some
way) passes on the URI to open to an already running Firefox and goes away
itself right after that.

Hmm, although at least for me with tabbed browsing turned on, the URI opens in a
new tab in an existing Firefox window, not a new window, so it is not completely
equivalent. Drats.
Comment 15 Mathias_Bauer 2009-06-09 13:30:59 UTC
Some applications do it like we do it, some others like we did it before. I have
planned to make a test using the following applications:

Windows: Firefox, MS Office, Adobe Reader
Linux: Firefox, AbiWord, Gimp, Adobe Reader
Mac: Text Editor, Image Editor, Safari, Adobe Reader

For all these applications I wanted to test the following scenarios (if applicable):

When the application is running already and has the focus

- open an existing document for it from the desktop (Explorer, Finder etc.)
- open an existing document from a shell
- open a new document from a link e.g. in a Start Menu

The same test then with the application running in the background. 

I'm still wondering if I have to test Gnome, KDE, xfce etc. and if Windows XP is
enough or I must test on Vista or Windows 7 Preview also ... On systems
supporting it, a test using "focus follows mouse" is necessary also.

I hope that these tests will show us something.
Comment 16 dykim6 2009-06-09 14:07:10 UTC
Firefox on Mac, too, please.
Comment 17 Olaf Felka 2009-06-26 11:22:14 UTC
*** Issue 102359 has been marked as a duplicate of this issue. ***
Comment 18 Mathias_Bauer 2009-06-26 12:31:18 UTC
Whatever we will do, we should at least bring document windows to front if a
dialog is opened inside of them.
Comment 19 kpalagin 2009-08-12 11:04:53 UTC
I guess this will miss 3.2 and more and more users will be clicking and 
clicking the files  and get angry only to discover at some later moment that 
dialog. What a damage to our reputation.
Comment 20 george_yves 2009-08-18 09:57:26 UTC
If you open a document, your goal is to edit or look through its content. You
want to do it now but not later, and you expect the window to open in foreground.

If you open Windows Explorer and double-click a document, your goal is to work
with the document but not to "play" with Explorer. So the document must be open
in foreground window.

Comment 21 Rainer Bielefeld 2009-08-18 14:13:41 UTC
For my user experience this is a P2 usability regression DEFECT. Full ACK with
kpalagin's and "george_yves".

If that's "good common behavior", please make OOo initiate WIN in such cases to
bring focus to new OOo windows.

I agree, for some cases the requested (old) behaviour might be not optimal, for
example, if you want to open several OOo documents from WIN Explorer one by one.
 Here it would be annoying if open OOo would change focus after every double-click.

Maybe we need a checkbox in the preferences "I prefer focus on new Docuemnts
opened from  EXPLORER" to fulfill need of those Unix nerds who dislike "change
focus" solution? ;-)
Comment 22 cno 2009-08-20 08:27:10 UTC
Hi Matthias,
Maybe I am more dummy than I thought, but I do have difficulty with the
behaviour myself ;-)
Because it works different when different applications have the focus. 
And because popups for passwords and macro-security remain hidden.
So be it a bug or enhancement: thanks for looking at this. 
Comment 23 Mathias_Bauer 2009-08-26 10:34:49 UTC
I think we already agreed that we should do something here, something along the
line of introducing a configuration setting and setting the default for it as
close to the expectation of the users as possible.

The implementation of this enhancement or bugfix (as you prefer to see it) is
not done in one day, even without the suggested testing with other applications.
So working on this issue would have taken away resouces from other things that
we already planned to do for 3.2. IMHO the importance of this issue is not big
enough to justify that. 
Comment 24 chojin 2009-09-22 15:40:41 UTC
Please reconsider for 3.2 as this bug (sorry, I really can't see this as an
enhancement) is really a show-stopper for the IT manager in our company because
this problem will flood our internal IT helpdesk as soon as a version with this
problem in it is deployed. And I can imagine that many people will think alike
and will block OOo versions with this problem in professional environments...
I also heard from a friend who has his own IT services company and tries to
promote OOo and convert as much other companies as he can to OOo, that he also
can't use versions with this problem (even though he did try for a while, but
had to downgrade them all because of the many user complains). Please don't
underestimate user-complaints, such an unintuitive thing like this can prevent
people from starting to use OOo..and should really be fixed as soon as possible.

I'm not an expert, and didn't look at the source, but if you want the OS to
decide if a window can come to the front then, in the Windows case, shouldn't it
be done by calling the Windows SetForegroundWindow Function as this function
brings a new window to the front when the calling thread is the active thread
(with user-focus). If the thread has no user-focus, the new window will start
blinking in the taskbar, not stealing any focus. Exactly like any other
application in Windows..
Comment 25 Mathias_Bauer 2009-09-22 16:14:08 UTC
Adding UI for 3.2 is not possible anymore.
All we could do is adding a configuration switch that can be set by manually
editing configuration files (or installing an extension containing the settging).

If you think that this is important enough, ask for promoting this issue as a
showstopper for 3.2 on our "releases" list.
Comment 26 lendo 2009-09-24 22:24:34 UTC
mba: Unfortunately it's futile for end users to ask for promoting an issue in
the mailing list. End users will mostly get back negative or no replies.

It's surprising and sad that 1) a developer can change behaviors like this in an
official release without a UX study(?) for all platforms and 2) users have to
wait min. 1 year (from OOo 3.1 to 3.3) to change this UX disaster back (because
of hidden dialogs the user is waiting for endlessly and because of windows
opened in the background). If it ever will get fixed (apparently you are the
only developer who cares about this issue).

BTW if I click on a document in Ubuntu's Nautilus then all applications open in
the foreground: Gedit, Firefox, Eye of Gnome, etc. So on Linux it's quite the
same as on Windows.
Comment 27 lleroy 2009-09-28 12:03:06 UTC
I hacked together a solution for this problem... you can find the diff at
Since the diff probably makes little chance to be incorporated in the official
version, I have posted a patched .dll on my page
Comment 28 Mathias_Bauer 2009-09-28 12:09:42 UTC
This patch fixes the problem at the wrong place. So use it at your own risk.
Comment 29 kpalagin 2009-09-28 13:34:19 UTC
could you at least specify what is write place to fix?

Comment 30 lleroy 2009-09-28 14:46:20 UTC
Hmm... as far as I can debug this, the "ToFront" is actually called by the
application and/or framework, it just doesn't do anything.

> This patch fixes the problem at the wrong place. So use it at your own risk.

You probably mean that instead of removing the "if"s, the flags need to be set
by the callers
Comment 31 Mathias_Bauer 2009-09-28 16:27:45 UTC
How many places are to touch depends on how complete the fix should be. If the
change should just bring all windows to front unconditionally (without any
options with or without GUI), there are either two places to change (sfx2 and
dbaccess) or - if we are lucky - only one in framework. I never had taken a
closer look if the "framework only" fix is possible, but I will when I find some

The reason why I think that fixing this in VCL is wrong: as the requirement to
bring application task windows to front is "application logic" it should be
fixed in application (or here: framework) code. VCL should just provide the
operating system functionality as-is.
Comment 32 carsten.driesner 2009-10-07 07:30:13 UTC
cd: Set myself and mav on CC.
Comment 33 mdxonefour 2009-10-12 13:26:22 UTC
MD: Raising priority, setting keyword "usability"
Comment 34 carsten.driesner 2009-10-12 14:29:44 UTC
cd: According to release status meeting this issue is now a OOo 3.2 show stopper.

cd: Set myself as owner of the issue. The responsible code is part of the
framework project.
Comment 35 carsten.driesner 2009-10-12 14:40:52 UTC
cd: Assign issue to myself.
Comment 36 carsten.driesner 2009-10-12 14:44:15 UTC
cd: Fixed in CWS fwk123. There is a new configuration item which controls the
focus/visibility handling of new document windows. The new entry is by default
set to "true" which forces a new document window to the front.
Comment 37 carsten.driesner 2009-10-12 15:38:14 UTC
cd: Add issue to the OOo 3.2 stopper list.
Comment 38 carsten.driesner 2009-10-14 10:35:43 UTC
cd->tm: Please verify. Look at the comments for the CWS. OLE must be tested
carefully with this fix. You should check all supported Windows systems, e.g.
2000, XP, Vista and Windows 7 (RC).
Comment 39 Rainer Bielefeld 2009-10-18 08:01:01 UTC
Can someone please check whether Issue 105465 really has the same roots and will
be fixed with the fix for this issue?
Comment 40 michael.ruess 2009-10-19 21:47:19 UTC
Tested OLE now on WinXP, WinVista, Win7 and Linux. Everything looks fine.
Comment 41 thorsten.martens 2009-10-20 09:00:59 UTC
Checked and verified in cws fwk123 -> OK !
Comment 42 Olaf Felka 2009-10-27 07:39:30 UTC
*** Issue 106298 has been marked as a duplicate of this issue. ***
Comment 43 thorsten.martens 2009-11-09 09:36:10 UTC