Apache OpenOffice (AOO) Bugzilla – Issue 123003
Text invisible while editing in particular old documents
Last modified: 2017-05-20 10:33:58 UTC
Created attachment 81301 [details] Sample Document Steps how to reproduce Reproducible with "AOO 4.0.0 – German UI / German locale [AOO400m3(Build:9702) - Rev. 1503704 2013-07-16 14:54:56 (Di, 16 Jul 2013)]" on German German WIN7 Home Premium (64bit)", Common 4.0-dev User Profile: 1. Open attached sample document from AOO Start center via File menu 2. Double click text box to get edit mode 3. Click behind first bullet before character of first list line 4. <Enter> for new line 5. <UpArrow> t get caret into first line directly behind bullet 6. Start typing Bug: New text sill become invisible when you stop typing for a moment. Additional info: a) Sample document is a reduced document created with LibreOffice, no problem there b) Was ok with AOO 3.4.1, so REGRESSION c) Started with or before Rev 1457992 d) The problem seems limited to a particular class of my documents. Even when I simply copy the text box to a blank new document the problem disappears.
There are lots of additional editing problems in with these documents, for example selection with dragged mouse button is difficult ... impossible
As given in description. Rev. 1503704 Debian
*** Issue 123012 has been marked as a duplicate of this issue. ***
This looks like duplicated of/related to Bug 122921
adding keyword regression according Rainer's description
ALG: The difference is that on the old stuff the frame around the activated text object keeps it's handles and keeps blinking, while for new ones the handles are taken away at edit activation and the blinking is stopped. Latter is how it should be. Checking why this happens with 'old' objects...
ALG: Comment accidentially added to #122920# adding here: ALG: It depends currently on the DragSingles setting which is part of the user settings; this is the flag which switches when entering/leaving single point mode. The error can be reproduced with a new doc when switching to PointEditMode and then working on a text object. The test document has this flag set in the user settings. Of course this sould be independent from PointEditMode; checking sources... New comment: ALG: This goes to old and dangerous stuff; it has to do with the EditEngine itself which gets for active text edit coupled with the active window; during text edit, it directly paints to that window (for repaints I already created a way to paint into another OutputDevice to get rid of the repaint flicker). Due to this direct painting into the window it collides with overlays, so no overlays are allowed during text edit. Thus, the text frame which can be seen during text edit is not part of the Overlay, but painted directly in the EditEngine/Outliner paint phase (SdrObjEditView::ImpPaintOutlinerView). BTW: This is one of the things I have on my list of necessary reworks... To solve this, there is already code in SdrMarkView::SetMarkHandles which avoids handle/overlay object creation (see bHideHandlesWhenInTextEdit and bHideHandlesWhenOleActive), but only in the case for bFrmHdl (the case in PointEdit mode). This needs to be done in all modes, so it needs to be moved outside. An alternative is to force to bFrmHdl with TextEdit. Trying this out...
ALG: Works as expected, checked also #122142# and activated OLE. Some more checks, preparing commit...
ALG: Requesting AOO401 release blocker flag...
ALG: Comitted, done. Waiting for flag...
"alg" committed SVN revision 1518697 into trunk: i123003 Corrected Handle/Overlay visualization when TextEdit is active
approve showstopper request
"alg" committed SVN revision 1518918 into branches/AOO401: i123003 Corrected Handle/Overlay visualization when TextEdit is active
ALG: Added to AOO401, done.
set target milestone
ALG: Corrected owner
*** Issue 123017 has been marked as a duplicate of this issue. ***
*** Issue 122921 has been marked as a duplicate of this issue. ***
It's verified fixed in build AOO401m4(Build:9713) - Rev. 1521921 with sample document attached