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
I was expecting the contents of A2 & B2 both to be pushed to A3 and B3
Discovered in Fedora 21 with 4.5 from the nightly builds
Build ID: ebfec3517d001f8aa8baaabde7c4af6b01347b95
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2014-12-06_00:52:12
Plus XP & LO184.108.40.206
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 220.127.116.11
(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
2 Foo Bar
- 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
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
We're replacing our use of the 'ux-advise' component with a keyword:
Component -> LibreOffice
Add Keyword: needsUXEval
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"
** Please read this message in its entirety before responding **
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa
Thank you for helping us make LibreOffice even better for everyone!
still repro in
Build ID: 757c58e8cb70b2982843211a54750fb3cd79acd5
CPU threads: 4; OS: Windows 6.1; UI render: default; VCL: win;
Locale: ru-RU (ru_RU); UI-Language: en-US