Apache OpenOffice (AOO) Bugzilla – Full Text Issue Listing
|Summary:||Cursor position and visible text area lost after desktop or window focus change|
|Status:||CLOSED IRREPRODUCIBLE||QA Contact:||issues@sw <issues>|
|Version:||OOo 1.1 RC2||Keywords:||oooqa|
|Issue Type:||DEFECT||Latest Confirmation in:||---|
Description philipp.lohmann 2003-08-21 15:05:30 UTC
Issue created on behalf of Robert Black Eagle who appended this unrelated bug to issue 8151: Quote: Rather than opening a new issue for this, I would like to comment on this issue and ask that it be reopened. I am running linux and just installed RC3. The problem existed in RC2 and in no previous versions I have used. If one switches from one window to another or to another desktop, on switching back to the first document, the cursor and screen focus are both moved at least two pages before the position before the switch. Typing any text restores the original focus and cursor position. To reproduce: Type any document of five or more pages (to get a feel for where the focus moves. Stop at the end of the document (cursor at end and focus on the last page). Move to another document or desktop. Move back. Result: focus has moved backward several pages and the cursor is also at that position. Typing anything causes a sudden flip back to the end of the document. Expected result: focus and cursor appear where they were before. Definitely a bug.
Comment 1 philipp.lohmann 2003-08-21 15:06:32 UTC
pl->ama: HDU can reproduce this on his desktop, i couldn't.
Comment 2 rblackeagle 2003-08-21 21:27:22 UTC
This may help: In linux (in Windows also?), the start up screen is 4/5ths the window size rather than full-window (maximized). The maximization is not saved from one opening to the next. This has been reported as a separate issue. I was told that the problem reported here (moving back by two pages when switching windows or documents) does not happen if the screen is not maximized. So I tried it and was very surprised: If the screen is not maximized and a document is opened, the screen remains at 4/5ths the size of the window. However, opening another document produces the weird result that the next window is full-size and remains full size for all future uses. Now, the problem with the focus moving backwards two pages does not happen on the screen at 4/5ths size but does on all full-sized screens. Is this of any help in diagnosing the problem?
Comment 3 philipp.lohmann 2003-08-22 09:29:38 UTC
HDU, AMA and me looked into the problem yesterday and found that on being unmapped (as a Window is when either desktop is switched or you iconify it) the application moves its view to accomodate the seemingly new width and height of zero of its application window (which is how being unmapped is reported).
Comment 4 philipp.lohmann 2003-09-09 11:02:05 UTC
*** Issue 19307 has been marked as a duplicate of this issue. ***
Comment 5 rblackeagle 2003-09-10 00:32:38 UTC
Initial problem no longer appears in 1.1RC4 based on my first test.
Comment 6 ruko 2003-09-10 09:20:59 UTC
At my SuSE 8.2 with KDE 3.1.3 and OOo 1.1 RC4 the bug is still there! (See Bug 19307): switching desktop/virtual screen loses focus, but keeps curser position. No other X Application has this bug, nor is the bug in the OOo spreadsheet.
Comment 7 philipp.lohmann 2003-09-10 09:28:42 UTC
I can still reproduce it, too.
Comment 8 andreas.martens 2003-09-10 16:27:15 UTC
Frank, AFAIK you fixed this zero problem, didn't you?
Comment 9 frank.meies 2003-09-16 07:54:04 UTC
FME->QA: Could you please verify this and set an appropriate target?
Comment 10 stefan.baltzer 2003-10-07 17:51:59 UTC
SBA->FME: Target set to "Office later". Reassigned to Frank.
Comment 11 stefan.baltzer 2003-10-09 14:30:16 UTC
SBA: I talked to FPE about this. He acknowledged that this is really hindering his everyday work. In my opinion, the change of desktops or windows is very common use (i.e. when making a lot of copy-paste actions between different applications/windows). I therefore set the target to "OOo 2.0".
Comment 12 stefan.baltzer 2003-10-09 14:33:18 UTC
SBA: Changed summary to meet the findings.
Comment 13 frank.meies 2003-10-10 13:55:15 UTC
FME->SBA: This problem does not exist anymore in my current SRX645m19, Linux. I think this has been fixed with i16909.
Comment 14 rblackeagle 2004-02-12 19:56:32 UTC
The problem still exists with 1.1.1b (running on linux).
Comment 15 rblackeagle 2004-04-24 20:22:16 UTC
The problem still exists in 1.1.2rc. The main issue is one of consistency. I have checked on my linux machine, my wife's Windows 95, my niece's Windows 98 and a friend's Mac and this is the current behavior for all applications EXCEPT OOo. Most applications remember the size when the program was last closed and open in that size. Some applications have a "Save Settings" button or option and take their opening size from that option (new size if saved, old size if not). OOo is the only application that does neither but opens in a reduced size every time. It is irritating and it recurs in 1.1.2rc. Since it did not do this in older versions (1.0 and below) it is doubly irritating in that it appears to be a regression on one wants to do anything about. Given fme's comment, I assumed the fix would be in 1.1.1, but it was not. I noticed that it is set for 2.0, so will make no further comments unless it fails to appear in 2.0.
Comment 16 peschtra 2004-12-26 19:16:59 UTC
Have you tried Tools > Options > OpenOffice.org > Views > Restore > Editing View. This should save the window size, hopefully resolving your not remembering window size issue. Is this being looked at for 2.0?
Comment 17 stefan.baltzer 2004-12-29 14:54:45 UTC
SBA: I cannot reproduce this in the current developer build. Can someone please give me a reproducible scenario for a OOo 1.9.68 build (680m68.8855) or younger. If so, don't forget to name the relevant Linux data (Window manager etc), thx. Please note: I am NOT interested in OOo 1.1.X scenarios (see target milestone!). Set To "Worksforme". This one will be closed unless I get a reliable OOo 2.0 cand. scenario.
Comment 18 stefan.baltzer 2005-03-18 18:29:45 UTC