Bug 36496 - content of frames and captions not editable in text document
Summary: content of frames and captions not editable in text document
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
3.4.0 Beta2
Hardware: All Windows (All)
: medium major
Assignee: Cédric Bosdonnat
URL:
Whiteboard:
Keywords: regression
: 36768 36798 36936 36983 36994 (view as bug list)
Depends on:
Blocks: mab3.4
  Show dependency treegraph
 
Reported: 2011-04-22 09:13 UTC by André Schnabel
Modified: 2012-04-21 00:35 UTC (History)
11 users (show)

See Also:
Crash report or crash signature:


Attachments
sample bug document, try to edit frame or image caption (82.35 KB, application/vnd.oasis.opendocument.text)
2011-04-22 09:13 UTC, André Schnabel
Details

Note You need to log in before you can comment on or make changes to this bug.
Description André Schnabel 2011-04-22 09:13:29 UTC
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.
Comment 1 vitriol 2011-04-22 09:23:17 UTC
I confirm under Win7.
Selecting frame e pressing Enter works. Click into frame broken.
Comment 2 Petr Mladek 2011-04-26 05:27:21 UTC
I am really unable to edit the mail address in the test document.

Cedric, will you have time to look at it?
Comment 3 Helmut Leininger 2011-05-02 00:04:15 UTC
The problem is still present in beta3. The cursor cannot be positioned inside a frame. This makes frames unusable
Comment 4 vitriol 2011-05-02 06:58:02 UTC
*** Bug 36768 has been marked as a duplicate of this bug. ***
Comment 5 vitriol 2011-05-03 06:23:16 UTC
*** Bug 36798 has been marked as a duplicate of this bug. ***
Comment 6 Olivier Hallot 2011-05-04 09:22:08 UTC
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.
Comment 7 vitriol 2011-05-07 07:24:03 UTC
*** Bug 36936 has been marked as a duplicate of this bug. ***
Comment 8 Cédric Bosdonnat 2011-05-07 11:49:50 UTC
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
Comment 9 vitriol 2011-05-08 22:32:01 UTC
*** Bug 36983 has been marked as a duplicate of this bug. ***
Comment 10 vitriol 2011-05-09 01:51:59 UTC
*** Bug 36994 has been marked as a duplicate of this bug. ***
Comment 11 Noel Power 2011-05-09 13:07:59 UTC
*** Bug 36982 has been marked as a duplicate of this bug. ***
Comment 12 migo 2012-04-16 02:44:51 UTC
Sabayon Linux - LibreOffice 3.5.1.2 the bug came again. Can't edit for example tables inside frames.
Comment 13 Duncan Lithgow 2012-04-16 10:33:46 UTC
Works fine for me. LibreOffice 3.5.2.2 Build ID: 350m1(Build:202) in Ubuntu 1204 beta
Comment 14 Roman Eisele 2012-04-17 12:58:17 UTC
(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?
Comment 15 Pedro 2012-04-17 13:55:07 UTC
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)
Comment 16 Petr Mladek 2012-04-18 02:48:39 UTC
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.
Comment 17 Pedro 2012-04-18 03:27:14 UTC
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.
Comment 18 Petr Mladek 2012-04-19 03:48:41 UTC
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.
Comment 19 Roman Eisele 2012-04-19 04:10:36 UTC
(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.
Comment 20 Pedro 2012-04-19 04:29:59 UTC
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.
Comment 21 Petr Mladek 2012-04-19 05:52:22 UTC
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?
Comment 22 Roman Eisele 2012-04-20 07:49:18 UTC
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 ;-).
Comment 23 Roman Eisele 2012-04-20 11:40:27 UTC
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.
Comment 24 Pedro 2012-04-20 11:50:39 UTC
@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)
Comment 25 Duncan Lithgow 2012-04-20 17:49:54 UTC
@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.
Comment 26 Pedro 2012-04-21 00:35:23 UTC
@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.