Apache OpenOffice (AOO) Bugzilla – Issue 99971
New file not in front window
Last modified: 2009-11-09 09:36:10 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.
adjusting settings
The same in Windows Vista and 7, new windows are opening in background. Confirming.
Happens also on XP SP3.
Its present in 3.1 and several platforms/OS
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.
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. :-)
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.
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.
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.
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.
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.
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.
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.
Reading those other bug reports I understand that this is a quite complex issue. Sigh. 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.
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.
Firefox on Mac, too, please.
*** Issue 102359 has been marked as a duplicate of this issue. ***
Whatever we will do, we should at least bring document windows to front if a dialog is opened inside of them.
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.
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.
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? ;-)
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.
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.
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..
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.
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.
I hacked together a solution for this problem... you can find the diff at http://lleroy.webs.com/BringToFront/ Since the diff probably makes little chance to be incorporated in the official version, I have posted a patched .dll on my page
This patch fixes the problem at the wrong place. So use it at your own risk.
Mathias, could you at least specify what is write place to fix? Thanks®ards, KP.
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
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 time. 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.
cd: Set myself and mav on CC.
MD: Raising priority, setting keyword "usability"
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.
cd: Assign issue to myself.
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.
cd: Add issue to the OOo 3.2 stopper list.
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).
Can someone please check whether Issue 105465 really has the same roots and will be fixed with the fix for this issue?
Tested OLE now on WinXP, WinVista, Win7 and Linux. Everything looks fine.
Checked and verified in cws fwk123 -> OK !
*** Issue 106298 has been marked as a duplicate of this issue. ***
closed