Open a document containing text frames and images/drawing objects. Use the Navigator for quick scrolling to an object. CASE A: text frames - double-click on a text frame name View scrolls to the target frame, cursor is positioned at head of first paragraph in the frame. Typing there is just as usual. Frame outline does not show the dimensioning handles (once again as expected because focus is on text entry). - double-click on another text frame Same behaviour, OK. CASE B: images/Drawing objects - double-click on a name View scrolls to the target. Frame outline is selected and shows the handles. Typing on the keyboard has no effect. This is as expected, no matter where you come from. Arrow keys move the frame, as expected. - double-click on another name Same behaviour, OK CASE C: mixed case, image then text frame - double-click first on an image/drawing object name Expected behaviour, see above. - double-click on a text frame name View scrolls to the target, but BOTH the frame is selected and the blinking cursor is positioned at head of first paragraph. If you start typing, the cursor jumps to last position of last paragraph and characters are added there. If, instead of typing "characters", you try to navigate with the arrow keys, this will change the position of the frame though I could not see exactly how (the frame itself remained at its position but the paragraph mark it was anchored to moved but aside the frame without exceeding the vertical limits). This seems to be a "mid-way" behaviour with part of image control, part of text control. In text, we don't expect the entry location to suddenly jump without user intervention (unless cursor positioning is wrong from the start. Where is it supposed to go when a frame is double-clicked in the navigator?) Anyway, this is not consistent.
This bug report is a follow up of https://ask.libreoffice.org/en/question/244071/writer-navigator-change-selected-frame-to-another-frame-results-in-new-frame-selected-but-positionresize-handles-not-visible/
Ajilttoz, thank you for reporting the bug. Please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it)
Update to bug information Carefully checking the scenario, the inconsistency only appears for Drawing object->Images/Text frames. Transition Drawing object->Image causes a blinking cursor to appear when it should not because an image is not a text frame. Text frame/Image->Text frame/Image, all combinations correct Drawinf object->Text frame/Image exhibits the faulty behaviour.
Created attachment 160921 [details] Document with text frames, images and drawing objects
I confirm it with Version: 7.0.0.0.alpha1+ (x64) Build ID: 99c337d1d3831ce9d2c7dc1cbff713f4ac49d6ac CPU threads: 4; OS: Windows 10.0 Build 18363; UI render: Skia/Raster; VCL: win; Locale: en-GB (de_DE); UI: en-GB Calc: CL Steps to reproduce 1. Open attachment 160921 [details] 2. Open navigator 3. In navigator double-click on Frame A => Cursor appears within Frame (O. K.) 4. In navigator double-click on Shape 1 5. In navigator double-click on Frame A Actual result: Frame is selected and cursor appears within Frame Expected result: Same as in step 3 Same result with double click on images after double click on Shape
Fix committed for bug 131218 also fixes this.
Tested again with Version: 7.2.0.0.alpha0+ (x64) Build ID: 9f9798f07f0b56ae474f31ded671cc8da598d244 CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: threaded Actual result: Behaviour is now consistent (what I can see): If you select frame or drawing object, cursor is always placed at the end of the text in drwaing object or frame. Curos is invidible, but that might be a different bug. I must admit, that I don't understand my own comment 5. So question to you, Ajlittoz: Can you verify, that this bug is fixed?
(In reply to Dieter from comment #7) > I must admit, that I don't understand my own comment 5. So question to you, > Ajlittoz: Can you verify, that this bug is fixed? I'm sorry, I can't. My policy is to use the version coming from my distro repositories. I'll have to wait until it bubbles up. Moreover, I need to fully reinstall my computer. So I try to minimise new installations to limit the backup volume. I keep you informed as soon as the operation is complete.
Verified in Version: 7.2.0.0.alpha0+ / LibreOffice Community Build ID: f2389a70da606768a39ee599de6a5b24058734aa CPU threads: 4; OS: Linux 5.8; UI render: default; VCL: gtk3 Locale: ro-RO (ro_RO.UTF-8); UI: en-US Calc: threaded In 7.0.4 the cursor stay in the shape, in 7.2 the cursor moves where I double clicked. It's ok now.