Apache OpenOffice (AOO) Bugzilla – Issue 19976
annoying raise behavior ...
Last modified: 2010-12-12 00:22:36 UTC
On Unix, if you're loading a document and it's taking time and you page it to the background to do something else - you get interrupted when it's finished loading by the application raising itself, which people get upset about - screws up focus unexpectedly, disrupts the new thing you were doing etc. The attached patch is what we apply to fix this.
Created attachment 9623 [details] no-raise patch
TM->PL: Please have a look, thanks !
pl->mba: a patch for framework
Sorry, but I'm afraid that this patch throws out the baby together with the bathwater. The first patch will cause focus problems when a view in a frame is exchanged (f.e. when a document is loaded into the "backing window"), so it can't be changed so easily. I'm not sure about the second patch (in implts_enableFrame). Unfortunately the developer working in that area is on vacation this week, so we should wait until he returned.
Sorry - but both patches are not acceptable. 1) Transfering the focus from the container window to the changed/new component window must be done (because vcl dont do it for us). Otherwhise we will run into focus problems as mathias already mentioned. 2) These lines was added for the internal bug #108807#. The situation before: a new loaded document into an existing frame (e.g. an empty document or into the backing window) doesnt bring the document to the right workspace (under unix!) if the recycled task was not part of the current visible workspace. Sorry - but I cant distinguish between an user, which wish to have any new loaded document visible or other ones, which doesnt whish to have such feature :-( And sorry again - we shouldnt make it "configurable"! => We have to discuss, how the general behaviour for a "ToFront"/"SetFocus" action should be.
OK - this patch isnt the right one ... but we implement the following behaviour: a) Inside setComponent() we can ask for the current focus state on demand (means the focus state of the container window) and transport this information directly to the new component window. That can minimize the count of setFocus() calls but its not possible to supress setFocus() at all! b) The call "ToFront()" inside "implts_enableFrame()" can be moved to the method "implts_findAndLockRecycleTask()". So the used backing window will be set to front BEFORE loading of the new document will be started. If the user page it to the background it will resists there till the user change that manually.
did you come up with a new patch for this ? and if so, how can I extract it from CVS ? Thanks.
No - there isnt currently a new patch. I will start it if time is available ...
AS->mmeeks. I'm back with a new patch :-) a) The document will be shown first time a progress is used. Of course it's set to front then too. b) Further the visibility of the document isnt touched. So the user shouldnt be interrupted on it's work (if he put such loading documents into the background). c) But: c1) If no progress is used at all (because e.g. the used filter doesnt suport that feature) the document will be shown on finishing the load process. c2) If somewhere else inside the office code creates a new feature (e.g. call's GrabFocus/setVisible/toFront/ToTop/... anyhwere) ... the old problem can occure again. So this fix cant be stable for the future ! From now: the framework will everything make right ... But it needs more then that. All (!) code of our applications must be aware of this feature.
AS-TM: Please verify this task. THX. re-open issue and try to reassign to tm@openoffice.org
try to reassign to tm@openoffice.org
try to reset resolution to FIXED
When loading a large writer document (which takes some time) and switching the office to the background to do some work in a different application (like mozilla... writing these words) the office suddenly pops up into the foreground when the document has been loaded. So this issue seems to be fixed but failed. re-open issue and try to reassign to as@openoffice.org
try to reassign to as@openoffice.org
AS->mmeeks: Soory .. but I#ve tried to implement this enhancement ... but it wasn't successfully. a) toFront() isnt the only function, which brings the document window realy to front. Every setVisible() / Show() / setFocus() / GrabFocus() call can do the same implicitly. But such calls was made more then once during loading ... I've removed it ... and got some strange effects. see b) b) On Windows it worked ... but produced some strange repaint and input errors. e.g. the writer cursor was damaged, the calc module redirects her key input events to the wrong document window (without changing the focus!). On Linux it doesnt worked in general. We have another feature, where we restore position and size of document windows dependend from the used application module. Of course that is done on the end of the load process. This resize on the top level window bring the window to front automaticly (on linux). May be that this depends on the used window manager. At least it was not possible to implement this feature realy. On the other side we accept the idea behind this patch as a good one .-) So we retarget this task to OOLater and may be we find a better solution if we can spend more time on this implementation.
I have a spreadsheet that I see this issue on every time I start up OpenOffice. The window opens and takes the input focus. Because it takes another several (8+) seconds before the spreadsheet is fully usable, I click on a terminal window and start typing at it. OpenOffice takes the focus back. I click on the terminal window again to give it the focus and continue typing. OpenOffice takes the focus back. This is annoying, especially since I now have to reload the spreadsheet. This is running OpenOffice 2.0 on SuSE 9.3, using GNOME. (That's the "final" 2.0, not the pre-2.0 that originally shipped with SuSE 9.3).
*** Issue 49426 has been marked as a duplicate of this issue. ***
Same problem Windows XP PRO SP2 OO 2.0.1 - focus is taken 2-3 times during load, which is quite annoying. Mozilla (Firefox/Thunderbird) had, I think, the same problem before, but fixed it somehow.
It's unclear to me whether a raise is ever justified at all. Why do all these random calls raise the window ? - that sounds broken to me. But perhaps I'm missing some useful scenario for window raising. Surely things like the floating-toolbar stuff can do their raise logic (if that is actually neccesary in code specific to that ?)
Because the patch is not really appliable I set "type" to enhancement
When working on issue 66239 I got some new insights. It seems that I finally was able to fix the problem. :-) I tested it on Windows XP and Suse Linux 9 and it worked as expected: if I send a window to the background after I started the loading procedure it stays there and doesn't come to front. If anybody wants to test it on his system: the CWS is called "inplaceobjects", I can provide Linux and Windows installation sets on demand.
In case this is the solution I will commit this to the next possible release.
Huraaa!
A hint for the QA how that could be tested: Start OpenOffice.org with an empty window or by loading a document Open a large document While the document loads, switch to another task window The window of the new document should stay in the background even after loading has finished. Please test under different platforms and - if possible - window managers.
please verify
*** Issue 62756 has been marked as a duplicate of this issue. ***
adjust target
It was not possible to fix all problems in the CWS inplaceobjects in time so all tasks will be moved to the next release.
Checked and verified in cws inplaceobjects -> OK !
target adjusted; CWS is too risky to integrate into 2.1 only 2 weeks before code freeze
closing ancient issues
Why was this issue closed instead of fixed, it appears the code was done but never integrated?
because a) it was integrated two and a half years ago in SRC680m192 b) the patched code doesn't even exist anymore
closing
This issue has reappeared in OO 3.3 pre2 and pre7 Can I reopen this issue?