Created attachment 45951 [details] sample bug document, try to edit frame or image caption In LibO 3.4 beta2 the content frames in text documents cannot be edited. To verify: open a new text document, choose insert - frame confirm frame dialog with defaults double click in the content area of the frame -> you cannot place the cursor in the content area -> expected is that you can edit the context I'll attach a very simple document which was created with a previous version. Just try to edit the mail adress.
I confirm under Win7. Selecting frame e pressing Enter works. Click into frame broken.
I am really unable to edit the mail address in the test document. Cedric, will you have time to look at it?
The problem is still present in beta3. The cursor cannot be positioned inside a frame. This makes frames unusable
*** Bug 36768 has been marked as a duplicate of this bug. ***
*** Bug 36798 has been marked as a duplicate of this bug. ***
The only way I have to go inside a frame with the mouse is through the navigator. Double click on the frame in the navigator window and the cursor jumps inside the frame for text typing or pasting.
*** Bug 36936 has been marked as a duplicate of this bug. ***
Fixed by this revert: http://cgit.freedesktop.org/libreoffice/writer/commit/?h=libreoffice-3-4&id=6f6a307824fdca340ee62c659024e470f7271dcc Faulty commit is now reverted in 3-4 branch and master
*** Bug 36983 has been marked as a duplicate of this bug. ***
*** Bug 36994 has been marked as a duplicate of this bug. ***
*** Bug 36982 has been marked as a duplicate of this bug. ***
Sabayon Linux - LibreOffice 3.5.1.2 the bug came again. Can't edit for example tables inside frames.
Works fine for me. LibreOffice 3.5.2.2 Build ID: 350m1(Build:202) in Ubuntu 1204 beta
(In reply to comment #12) > Sabayon Linux - LibreOffice 3.5.1.2 the bug came again. Can't edit for example > tables inside frames. I can't reproduce the (returned) bug with LibreOffice 3.5.2.2 (Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f) on MacOS X 10.6.8 German. Everything seems to work as expected for me, both if I follow the steps given by André in the original description and if I insert a table into a frame (as mentioned in comment #12): all fields/table cells are editable. @migo: Can you describe more exactly what you see? Can you attach a sample document with some frames/tables/... you can't edit?
Following the instructions from André, the bug still occurs under Windows with LO 3.5.2.2 If someone can confirm that this now also occurs under Linux, please change the Platform from Windows to All (even if it works on Mac)
I am unable to reproduce the problem described in the original comment with LO-3.5.2.2 on Linux (SLED11-SP1-x86_64). I can edit text in a newly created frame in a new document. Also I could edit address in the test document caras.odt. Heh, I see some strange thing. If I open the test document caras.odt, add a new frame using Insert/Frame, it is added under the picture and I can't edit it. If I resize the picture, I can edit it again. I am not sure if it is a bug. I wonder if this is what Pedro saw.
Resizing the frame still doesn't allow to edit. Only pressing Enter allows editing. I just tested this is in LOdev 3.5.3rc0+ Build ID: 47fce99-a73d29c-6845e52-f269e46-186d9ed and 3.6.0alpha0+ (Build ID: e00e693) and the bug is still there.
Hmm, I am unable to reproduce the problem with LO-3.5.2.2 on Windows XP SP3. I can edit the address in the test document caras.odt... Pedro, could please attach a screenshot and create circle about the frame that you cannot edit? I want to be sure that we do the same thing.
(In reply to comment #16) > Heh, I see some strange thing. If I open the test document caras.odt, add a new > frame using Insert/Frame, it is added under the picture and I can't edit it. If > I resize the picture, I can edit it again. I am not sure if it is a bug. Very interesting. I can reproduce this behaviour with LibreOffice 3.5.2.2 (Build-ID: 281b639-6baa1d3-ef66a77-d866f25-f36d45f) on MacOS X 10.6.8. It is, well, really a bit strange.
This is a problem with the mode. When you create a new frame it will show the green dots (meaning you can re-size and modify the frame). Double clicking anywhere inside the frame when the green corners are showing will display the config dialog. The only way to get into edit mode is to a) press Enter or b) click on any other object on the document or any empty area outside the frame. This will switch the frame out of config mode. Clicking inside the frame now will allow to enter text. @Petr: answering your question, I can edit any frame because they are in edit mode. But create a new one as per André's instructions and you will see the problem.
I see exactly the same behavior in LO-3.4.6 and LO-3.5.2 on Linux! A) if I click inside a non-selected frame, it puts cursor there and I can edit the text B) if I select the frame by clicking on the border, it shows the green dots, so I could resize it: 1) if I click inside this selected frame, it shows nothing; though if I start typing, it removes the green dots, put cursor at the end of the text inside the frame and adds letters as I type; so I could actually edit the text 2) if I double click inside this selected frame, it shows the frame option dialog I think that the behavior "B1" is a bit confusing because I am able to edit the text but I do not see the cursor until I write the first letter or press enter. IMHO, it should show the cursor in this case. IMHO, the original problem was different. If you read the comment #2, I was not able to edit the address at all. I guess that I tested the scenario "A". Also vitriol's comment #1: "Click into frame broken." looks like to be about the scenario "A". Pedro, do you see any difference between LO-3.4.6 and LO-3.5.2?
Petr, thank you for your excellent summary of the current behaviour! Personally, I doubt that there is a bug at all, and I can't find any regression relative to LibreOffice 3.4.x on MacOS X. Maybe what is needed is rather a discussion if the current (and old) behaviour should be changed, and this would be an enhancement, not a bug. The 'Importance' pickers may be of low importance, but it's ridiculous that they are still set to high/critical/blocker, so I take the liberty to set them to medium/major (I would prefer low/minor, but I don't want to begin another priority war ;-).
Please forget the 2nd and 3rd paragraph of my previous comment; its wording may be inappropriate (too hard), I don't know why myself. All I wanted to say (and should have said) is: -- I suggest we should consider the "returned" bug as less important (severe) than the original one. -- I even suggest, after testing the behaviour of LibreOffice 3.4.x and 3.5.x, and playing around with selected and non-selected text frames for about half an hour, that (instead of talking of a bug) it might be better to talk about a possible enhancement, which would change the current behaviour. Some discussion might be necessary, of course, which behaviour is best for most users, and for this discussion a separate request (a enhancement requenst instead of a bug report) might be appropriate. Sorry again if I interfered with your discussion, and if my wording was inappropriate.
@Petr, there is no difference between any version. I even tried 3.3.4. So this has always been there. @Roman, what paragraphs? ;) I think that when a feature doesn't work as expected, it is a bug, not something that needs an enhancement. Maybe this should be discussed at the UX mailing list? (I'm not volunteering since i'm not subscribed to the list)
@Pedro: if every function that didn't work as someone expected was a bug we'd never get anything done ... If the current implementation can work once you understand it, then I agree that further discussion of the problems described here should be on enhancing the function to be more intuitive.
@Duncan, the problem here is in André's description. A BUG does occur when you follow the step-by-step instructions (i.e. insert a NEW frame). I will create a new BUG report for this. The Bug that prevented editing the text in an EXISTING frame in the attached document seems to be fixed, so I'm changing this to WORKSFORME.