Created attachment 64300 [details] Apex document template The attached document was created with an older version of OpenOffice. There is a table in the header. Since LibreOffice 3.5 (can't remember exactly from what version), it is impossible to edit the table in the header anymore. Otherwise, congratulations for this great software !
Confirmed (on WinXP 32b) with - LibreOffice 3.5.5.3 Build ID: 7122e39-92ed229-498d286-15e43b4-d70da21 - LibO 3.6.0.1.rc (Build ID: 73f9fb6) - Version 3.7.0.0.alpha0+ (Build ID: 146b507) Works fine with - LibreOffice 3.4.6 OOO340m1 (Build:602) - LibreOffice 3.3.4 OOO330m19 (Build:401) tag libreoffice-3.3.4.1 Related bug reports: - Bug 51126 - Text frame box not editable - Bug 49555 - EDITING: improve access to contents in Frames with wrap=through and "in background" option - Bug 47138 - FILEOPEN: .dot file import uneditable header footer without user action, page number rotated Workaround: (1) - Go to Navigator - Select: Tables > Table 3 - Navigate with the arrow keys / edit (2) - Select the frame (outer table borders) - Press <F2> - Navigate with the arrow keys / edit (3) - Select the frame (outer table borders) - Context menu: Frame... - Tab: Wrap > Options ☐ In background [disabled] - Edit
so it looks like this problem was introduced in the libreoffice-3-5 branch between 3.5.2 and 3.5.3; reverting these 2 commits enables cursor movement into the table in header again: b4b8f6966d5c2d308874f6213e68ecc620e92777 "n#750258: removed strange non-wrapping condition" 347bb1634b10eba577742fe8a7edb4b2dd69265d "Revert "make text wrapping work in headers/footers too (fdo#39155)""
this bug is quite peculiar... some more investigation lets me think that the object in header wrapping changes only affect this by accident; there is another commit that also has an effect; reverting this line from commit 8e17c11e25d7e0ecd3a8a5ab4a4a3bd98d8c81b7 seems to fix the bug: @@ -274,7 +276,7 @@ sal_Bool SwPageFrm::GetCrsrOfst( SwPosition *pPos, Point &rPoint, } // TODO Pick up the best approaching selection - if ( bTextRet && bBackRet && ( nTextSurface < nBackSurface ) ) + if ( bTextRet && bBackRet && ( nTextSurface > nBackSurface ) ) { bRet = bBackRet; pPos->nNode = aBackPos.nNode;
oh, forgot to say that the table is inside a frame that has Wrap set to "In Background"; changing to any other Wrap allows placing the cursor inside already.
*** Bug 51306 has been marked as a duplicate of this bug. ***
*** Bug 55842 has been marked as a duplicate of this bug. ***
*** Bug 56570 has been marked as a duplicate of this bug. ***
Created attachment 70433 [details] patch that doesn't solve the problem from a couple weeks ago, an attempt at solving the problem that did not work. problem is that the GetCrsrOfst method of the text lines return a hit up until the right margin, even if the text did end earlier.
Focusing is similar problem for drawing objects (shapes inserted by the Drawing bar), too, except, when the shapes are anchored to the paragraph of the header. In the attached document, selection works only for the middle star (the star anchored to the paragraph of the header), but after the selection, you can select the other ones (the stars anchored to the first paragraph of the document), too.
Created attachment 70436 [details] Test example with shapes
I'm currently working on that one... though there is no easy/obvious solution. The main problem behind this bug is what to select when you have text and background object. The whole story is that before I changed anything around that we were selecting background objects instead of text... which leads to troubles when you have some huge objects in background behind the text. The problem is to come with a way to determine the most accurate one to select... As Michael said (and the problem with the first sample document), when clicking the GetCrsrOffset finds the text even though there is no text under that position, but we may have the case with text going over the frame/object.
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=e8fbe97900f13305b17015d9044993bde4adab36 fdo#52182: Fixed click in frames located in header/footer The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
The problem should now be fixed, with the recent commits.
LibO-Dev_4.0.0.0.alpha1+ Win-x86@6 MASTER pull time 2012-12-02 05:22:03 core:704fdf2b23d0e0480f29e0e56f631c2835eed02b (on WinXP) Tested attachment 64300 [details] Apex document template Tech doc template - rev 2.7.odt Works fine for me.
I am comming from bug 47138. Please backport this to 3.5.x branch as this is very annoying issue for ~100 users in my organization. Then I will hope for 3.5.8 final release one day...
*** Bug 47138 has been marked as a duplicate of this bug. ***
back-porting to at least 3.6 seems like a good plan if possible (?) :-) Cedric / Michael ?
Cedric Bosdonnat committed a patch related to this issue. It has been pushed to "libreoffice-3-6": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d0a4a025855d78cdce194885c4df024c499bade6&g=libreoffice-3-6 fdo#52182: Fixed click in frames located in header/footer It will be available in LibreOffice 3.6.5. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 51126 has been marked as a duplicate of this bug. ***
*** Bug 58603 has been marked as a duplicate of this bug. ***
i'm having this problem since october, and even with Version 3.6.5.2 (Build ID: 5b93205) it doesn't work, although this bug is marked as resolved :-(
@Andreas Ziegler <https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs> Please only reopen a bug if you (at least) still can reproduce the bug from original report with original sample document. I am pretty sure that you have a problem with similar symptoms, but different roots. If you can reproduce the original bug as stated above please contribute exact details. If you can't reproduce the original bug, please open a new Bug for that problem and add me to CC!
(In reply to comment #22) > @Andreas Ziegler > <https://wiki.documentfoundation.org/BugReport_Details#How_to_reopen_Bugs> > Please only reopen a bug if you (at least) still can reproduce the bug from > original report with original sample document. > > I am pretty sure that you have a problem with similar symptoms, but > different roots. > > If you can reproduce the original bug as stated above please contribute > exact details. > > If you can't reproduce the original bug, please open a new Bug for that > problem and add me to CC! I have the problem described in https://bugs.freedesktop.org/show_bug.cgi?id=55842 they write, that the problem should be fixed with the patch to this bug here - but it isn't, so i probably was wrong commenting here, i'm sorry. the test files in this bug work for me, that's right.