Description: If a table is inserted into a Writer file and moved to the next page with Ctrl + Enter, the table is moved to the next page. If you want to move it back, the table stays where it is Steps to Reproduce: 1. Write some text in a new writer file 2. Add a new table below the text 3. Move the cursor to the end of the text and move the table to a new page with Ctrl + Enter 4. Delete the empty line that is now above the table on the second page 5. Try to move the table back to the first page by trying to erase the 'newpage' line or by cut & paste (Ctrl+X & Ctrl+V) the table to the first page Actual Results: The table will not move to the original page by just deleting the newpage line or by cut & paste the table Expected Results: The table should act like any other paragraph and should be movable with deleting the newpage line or cut & paste Reproducible: Always User Profile Reset: No Additional Info: There is a way around this, but I think it is incredibly bad. Assuming you are at step 5.: Place the cursor in the first cell of the table and add a new line (If there is text in the first cell, place it in front of the text). This will add a line above the table and the table can be moved again. If it is meant to be that way to somehow 'fix' a table in place it is incredibly bad in my opinion. I expected the table to behave like a regular paragraph or image that behaves like text. I discovered this workaround just by coincidence and it's everything but obvious. -------------------------------------------------- Version: 7.1.4.2 (x64) / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 16; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-AT (de_AT); UI: de-DE Calc: CL I know I should test it with the latest version, but right now I am unable to download the 7.2 version from the LO download page (and I have no idea why). Once I got the new version I will test the bug again (but I assume that it will still be there)
Created attachment 174574 [details] Bug 144121 - Table Newline bug The file is at step 5. from the description. You can try to remove the Newpage line after the text on the first page and it will not move the table.
UPDATE: I tested the bug with version 7.2.0.4 (x64, Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b) and it still exists.
No repro Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 8; OS: Linux 5.3; UI render: default; VCL: kf5 (cairo+xcb) Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
Repro in Version: 7.1.4.2 / LibreOffice Community Build ID: a529a4fab45b75fefc5b6226684193eb000654f6 CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded and Version: 7.2.0.4 / LibreOffice Community Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b CPU threads: 4; OS: Linux 5.10; UI render: default; VCL: gtk3 Locale: fi-FI (fi_FI.UTF-8); UI: en-US Calc: threaded and Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4debb7e8cc12563f46d1aaa58afdcb831f21cc83 CPU threads: 8; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win Locale: fi-FI (fi_FI); UI: en-US Calc: CL
If you add some text in front of the table at page 2, the text and the table move up as expected when using the backspace key. Of course, it should move up without any additional text.
(In reply to Henrik Palomäki from comment #5) > If you add some text in front of the table at page 2, the text and the table > move up as expected when using the backspace key. Of course, it should move > up without any additional text. You don't even need the text, the empty line before the table is enough. The empty line can be deleted though and it's not obvious how to get it back.
Please search in existing bugs for similar report. And attach a sample file so that test is simple.
(In reply to Timur from comment #7) > Please search in existing bugs for similar report. > And attach a sample file so that test is simple. It's not meant to be rude, but this sounds just like a generic comment. I searched for the bug before creating the report, but I didn't mention it explicitly. However, there certainly is a sample file that is ready to test that also includes a description what you need to to/test.
In the table properties -> Text Flow, there is the setting to add a page break before the table. I expect that is what you are running into. However, I was able to remove it by deleting the "blue line" page break, and the table moved back to page 1. Cutting the table won't work, because the table has the property to "page break before". I'm not sure exactly how you are trying to "5. Try to move the table back to the first page by trying to erase the 'newpage' line", but you should be doing that via the dotted blue line between the pages which visually indicates a page break, and editing or deleting it should provide you with the results you are looking for. So far I don't see any bug.
(In reply to Justin L from comment #10) > In the table properties -> Text Flow, there is the setting to add a page > break before the table. I expect that is what you are running into. > > However, I was able to remove it by deleting the "blue line" page break, and > the table moved back to page 1. In that case there seem to be two more solutions to the problem. However, none of them are quite obvious. > I'm not sure exactly how you are trying to "5. Try to move the table back to > the first page by trying to erase the 'newpage' line", but you should be > doing that via the dotted blue line between the pages which visually > indicates a page break, and editing or deleting it should provide you with > the results you are looking for. When you import an image, anchor it as text and move it to the next page with Ctrl+Enter, you can easily get the image back on the first page by just placing the cursor in front of the image or after the last character of the text and deleting the page break. > you should be doing that via the dotted blue line I don't agree with this. If so no page break should be deleted by pressing 'backspace' or 'delete'. Deleting a page break like it was a single character is what users come to expect to work. And either there is a clear indication of how it should be done or you should be able to do things in the way you are used to.
(In reply to BDF from comment #11) > or you should be able to do things in the way you are used to. I don't think you have ever been able to clear the table's break-before in any other way. The way you are "used to doing it" is to erase the paragraph. If you remove the table, that will also get rid of the page break. The comparison to an image doesn't count, because images don't have a property to "page break before".
(In reply to Justin L from comment #12) I agree. However, we *could* possibly introduce a special handling of backspace in the very first position in a table, when it has the said property ... not that it would be consistent internally, but *maybe* it's reasonable UX-wise? Adding UX to the discussion.
Ctrl+Enter is a page break. Adding it after the paragraph also moves the table to the next page but with an empty paragraph before. Removing this page break is simple. But when it is part of the table we cannot distinguish between deletion within the cell vs. outside. The same applies btw. to tables at the very first document position. You can add the page break per alt+enter in this case. Deleting at the first paragraph moves the table back meaning clears the page break. I don't see a solution other than removing the page break attribute from table properties and always bind breaks to paragraphs. Cor, we had this or similar discussions in the past. What's your take?
Putting all together the issue is not a bug. To delete the page break you have to go to the table properties. If backspace at the beginning of the top-most table cell (left or right depending on language) makes the cursor go out of the table, otherwise backspace deleting characters before is even weird, it might feel unstable.