Hi Tim,
because before enter the text in the cell I think it can't be moved, and insert doesn't automatically.
Pressing esc at the step to insert lets the cell empty.

If someone can advise whether this is a bug (enhancement) or not we can move forward.

This is something I did by mistake and noticed the odd behaviour. I can see there is a practical workaround so I am not troubled if this is closed :)

Think yourself if you want it as enhancement, I think it's not a common situation.

I am going to flag this as a low level enhancement. I appreciate it is an unusual activity but it can happen.

TESTING with Ubuntu Fourteen dot oh four and LO 4.4.0.2

(In reply to Tim Lloyd from comment #0)
> Open a calc doc
> enter text into A2
> tab to B2
> enter text (DON'T PRESS ENTER OR TAB)
> Click Insert and Row
> the text in B2 does not move but the text in A2 is pushed down to A3

CONFIRMED: Only the text in A2 is moved down

> I was expecting the contents of A2 & B2 both to be pushed to A3 and B3
> 

Yep, I can see how this behavior doesn't jibe with how we perceive items in boxes in the real world.

(In reply to m.a.riosv from comment #1)
> because before enter the text in the cell I think it can't be moved, and
> insert doesn't automatically.

I can believe that before we enter text into a cell, the editing region kind of "floats" above the cell. In fact we can see this more clearly if we do another test:

- Open Calc
- Put 'Foo' in A2 and 'Bar' in B2

   A    B
1
2 Foo  Bar
3

- Hit TAB to make sure the text is fully entered into the last cell
- Now click on B2 and type 'Baz' (AND DON'T PRESS ENTER or TAB)
- Click Insert -> Row

You'll now have the following

   A    B
1
2      Baz
3 Foo  Bar

Here's how I see the current paradigm:
- You have a big grid of cells, and one bucket
- If you click on a cell and start to enter text, you're really putting the text into this bucket that's in essence *hanging above* the cell.
- It's only once you hit ENTER or TAB that the bucket tips over and the value falls down into what's underneath it.
- Before you tip the bucket, anything done to the grid below (e.g. adding a row) only affects/moves the grid; it doesn't do anything to the bucket.

Do I like this paradigm? Well, I think it's more confusing than having the bucket move with the grid below whenever a row/column is added.

Status -> NEW

Handing this one to the UX Team.
Component -> ux-advise

Changing the insert row/col behavior doesn't fix the issue. Rather the workflow is error-prone when a user can modify the sheet while she is in edit mode. So the solution is simply to disable the sheet features, which is by the way how it works in Excel.

Changing the summary from "calc - inconsistent behaviour when inserting row before pressing enter"

still repro in

Version: 6.2.1.1
Build ID: 757c58e8cb70b2982843211a54750fb3cd79acd5
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win; 
Locale: ru-RU (ru_RU); UI-Language: en-US
Calc: threaded

Dear Tim Lloyd,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
 
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)


If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword


Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

MassPing-UntouchedBug