Steps to Reproduce: 1. Create a table with a least two columns and two rows, and add some text in each cell (see below a sample file taken from other bug report). 2. Select a cell and copy (Ctrl+C) 3.a. Select a lower cell and paste (Ctrl+V). 3.b. Select the lower cells and paste. 3.c. Select an upper cell (not first column) with text and paste. Actual Results: After step 3.a., the source (copied) cell is pasted in the selected cell and in the upper cell as a new inner table cell (i.e., Table2:A1). After step 3.b., the source (copied) cell is pasted in the selected cells. After step 3.c., the source (copied) cell is pasted in the selected cell as a new inner table cell, replacing the actual content, and adding new paragraphs above and below. Expected Results: After step 3.a., upper cell remains without changes. After step 3.c., the source (copied) cell is pasted in the selected cell as the cell content, replacing the actual content. Sample file: https://bugs.documentfoundation.org/attachment.cgi?id=176974 A table with two columns and two rows and some text Additional info: Related to tdf#146275. I can not repeat now, but while testing, pasting in the cell B1, clipboard content become pasted in A1 as a new inner table cell.
Reproducible with: Version: 7.2.3.2 / LibreOffice Community Build ID: 20(Build:2) CPU threads: 1; OS: Linux 5.3; UI render: default; VCL: gtk3 Locale: es-MX (es_ES.UTF-8); UI: en-US Calc: threaded
The same happens if do you select a cell in a table and paste some text; it became pasted also in the upper cell. If there is text in the upper cell, the pasted text is added at the end of it. The issue stops after some activity (not sure what one), but can reactivate later. New tables ever shows the issue, although it may be a table that already do not shows the issue at the moment. Reproducible with: Version: 7.2.7.2 (x86) / LibreOffice Community Build ID: 8d71d29d553c0f7dcbfa38fbfda25ee34cce99a2 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: en-US Calc: threaded Reproducible with: Version: 7.4.0.0.alpha1 (x86) / LibreOffice Community Build ID: b871abad383583f02eb49c7e49aeae01f6941072 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: es-ES Calc: threaded
I confirm described behaviour with Version: 7.5.0.0.alpha0+ (x64) / LibreOffice Community Build ID: ce29e6299932fc079b05b60662ba95c8342990bc CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL (In reply to LeroyG from comment #0) > Steps to Reproduce: > 1. Create a table with a least two columns and two rows, and add some text > in each cell (see below a sample file taken from other bug report). Each cell must have at least two paragraphs to get described result of 3a and 3c > 2. Select a cell and copy (Ctrl+C) > 3.a. Select a lower cell and paste (Ctrl+V). > 3.b. Select the lower cells and paste. > 3.c. Select an upper cell (not first column) with text and paste. Actual result (more general): 1. If one cell is selected, the source (copied) cell is pasted in the selected cell as a new inner table cell, replacing the actual content, and adding new paragraphs above and below. (step 3a and 3c) 2. If more than one cell is selected, the source (copied) cell is pasted in the selected cells. (step 3b) Expected result Not sure about the expected result, but I can see inconsistency here and so I would consider this as a bug. cc: Design-Team for further input
Both source and target cells need to be selected as a whole and require at least one paragraph break. No difference between above or below the source. Somewhat artificial issue since most users select the cell content with ctrl+A. If copying/inserting a cell is treated differently it should be done consistently. Meaning if two cells are selected (the more reasonable use case) and one pastes into one selected cell it should be inserted as children aka nested cells/table and not spread to the next cell (which happens now unless the target contains a PB). Could personally also live with a simple always flat approach (no nested tables) but that feature might be required by some users. Mike, what do you think?
Created attachment 181529 [details] Screencast
(In reply to Heiko Tietze from comment #4) > […] most users select the cell content with ctrl+A. I am not sure of that.
Created attachment 181542 [details] Screencast All done with keyboard. First I select (Shift+Arrows) and copy (Ctrl+C) the cell A1, then select (Shift+Arrows) different cells and paste (Ctrl+V).
Forgot to say that after each Ctrl+V follows a Ctrl+Z.
We discussed the topic in the design meeting. Nested table is a requirement (see META ticket under Blocks) and a ODF feature. We have to support it. Not least as MSO has the same feature (import/export works well). Inserting a nested table is possible, although one has to meet a couple of preconditions (see comment 4). But it's always possible to insert a table into a cell. There is no bug.
(In reply to Heiko Tietze from comment #9) > Nested table is a requirement. That is not in discussion here.
(In reply to LeroyG from comment #10) > > Nested table is a requirement. > That is not in discussion here. Please elaborate if we missed the point of your report.
Created attachment 187525 [details] Bug steps explanation
Also, see screencast in comment #7.
(In reply to Heiko Tietze from comment #11) > Please elaborate if we missed the point of your report. I added comments between (-- --). (In reply to Dieter from comment #3) > Each (--upper--) cell must have at least two paragraphs (--this is very important--) to get described result of 3a and 3c (--I separated steps 3.a. and 3.b. and its results--) (In reply to LeroyG from comment #0) Step 3.a. Select a lower cell (--say A2--) and paste (Ctrl+V). Actual Results: The source (copied) cell is pasted (--both--) in the selected cell (--A2, this is correct--) , and in the upper cell (--A1, that was not selected, and this is not correct--) as a new inner table cell (i.e., Table2:A1). Expected Results: Upper cell (--A1--) remains without changes. Step 3.c. Select an upper cell (not first column) (--say B1--) with text and paste. Actual Results: The source (copied) cell is pasted in the selected cell (--B1--) as a new inner table cell, replacing the actual content, and adding new paragraphs above and below. (--here is another problem: the paragraph below the new inner table hides, but reappears when the text cursor passes through it--) Expected Results: The source (copied) cell is pasted in the selected cell (--B1--) as the cell content, replacing the actual content. (--not adding new paragraphs, nor inner table--) Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: es-MX (es_ES); UI: en-US Calc: CL
If the text cursor is at the beginning of a cell text, pasting another cell will replace the actual cell content with the content of the source cell, not adding an inner cell. That seems correct to me. If the text cursor is at the first paragraph of a cell, pasting another cell will replace the actual cell content with the content of the source cell, not adding an inner cell. Not sure if that is correct. If the text cursor is below the first paragraph of a cell, pasting another cell will add an inner table cell, not replacing the actual cell content. That seems correct to me.
Created attachment 189089 [details] Screencast multiple nested cells (In reply to LeroyG from comment #14) > Expected Results: > The source (copied) cell is pasted in the selected cell (--B1--) as the cell > content, replacing the actual content. (--not adding new paragraphs, nor > inner table--) You need to be able to overwrite/delete the content as well as to add new. And both is possible, see the attached screencast.
There indeed is complete chaos here. After I copied a whole cell: 1. Selecting a whole cell with a single paragraph of text (no matter if it's empty or not), and pasting, replaces the target cell with the copied cell (no inner cell); 2. Selecting a whole cell with multiple paragraphs of text (no matter if they are empty or not), and pasting, clears the target cell content, and puts an empty paragraph, an inner table with the copied cell, and an empty paragraph (the latter would hide upon exit from the cell); 3. Putting cursor into the first paragraph (no matter which position inside that paragraph; selecting some characters starting from that paragraph works the same) inside the target cell, and pasting, replaces the target cell with the copied cell (no inner cell); 4. Putting cursor to any other paragraph inside the target cell (or selecting some characters starting from there), and pasting, splits the target cell text at the cursor position, and places an inner table with copied cell there. I can *not* see how any user (including advanced users) could make any sense of this. I could see if it would always put inner tables when cursor is inside the cell, splitting the text in the cursor position; and replacing the cell without creating inner cells, when selecting the whole target cell; I could understand if special keys could modify the paste result (Alt, Shift...) - but e.g. 2 makes *absolutely* no sense at all. Why should 1 differ from 2? Why 2 needs to have a *leading* empty paragraph? Why its text must be cleared, if it (at least its paragraph count) is considered when pasting? 3 vs. 4 is also unclear. Why I can't split 1st paragraph? If 3 is so much wanted, why not limit 3 to only empty cells - so that user would just del everything in advance in that cell which they intend to replace? Setting NEW. It needs a UX evaluation - not "if it is a bug", but "how to improve".
(In reply to Heiko Tietze from comment #16) > You need to be able to overwrite/delete the content as well as to add new. > And both is possible, see the attached screencast. Why, if I select and paste in cell A2, it becomes also pasted in cell A1? (In reply to LeroyG from comment #13) > Also, see screencast in comment #7.
(In reply to LeroyG from comment #18) I couldn't repro *that* piece using 7.6.0.3.
Reproducible with: Version: 6.4.7.2 (x86) Build ID: 639b8ac485750d5696d7590a72ef1b496725cfb5 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: default; VCL: win; Locale: es-AR (es_MX); UI-Language: en-US Calc: threaded A bit different at (will test latter): Version: 7.6.0.2 (x86) / LibreOffice Community Build ID: 41d6f628ba3f046f16b5fa9fa8db8d4c2ab3b582 CPU threads: 4; OS: Windows 6.1 Service Pack 1 Build 7601; UI render: Skia/Raster; VCL: win Locale: es-MX (es_MX); UI: en-US Calc: threaded
(In reply to Mike Kaganski from comment #19) > I couldn't repro *that* piece using 7.6.0.3. Nor with version 7.6.0.2 (just tested). So, the bug to which the title refers (*3.a* in comment #0) was partially solved somewhere between versions 7.5.0.0.alpha0+ and 7.6.0.2. (In reply to Mike Kaganski from comment #17) > 3. Putting cursor into the first paragraph (no matter which position inside > that paragraph; selecting some characters starting from that paragraph works > the same) inside the target cell, and pasting, replaces the target cell with > the copied cell (no inner cell); The same in version 7.4.7.2. But this behavior has been evolving: i.e., in version 6.4.7.2 this results in an inner cell inserted at the text cursor position (in part like *4* in comment #17), except when the cursor is at the beginning of the cell.
Someone please update regarding the status of this bug, which I can't reproduce with v7.6.0.3 and apparently other commenters as well. Is it completely gone? Does it occur in other cases? What's the ask right now? I'm confused.
(In reply to Mike Kaganski from comment #19) > (In reply to LeroyG from comment #18) > > I couldn't repro *that* piece using 7.6.0.3. Mike, you've changed bug status from RESOLVED NOTABUG to NEW, but I can't understand why. So I will change back to RESOLVED NOTABUG. Please explain why you think, we should chenge it to NEW => RESOLVED NOTABUG
(In reply to Dieter from comment #23) > Mike, you've changed bug status from RESOLVED NOTABUG to NEW, but I can't > understand why. So I will change back to RESOLVED NOTABUG. Please explain > why you think, we should chenge it to NEW Read comment #17.
Whether NAB/INV or not, the function is a very rare use case (not pasting but inserting a new table works out of the box). Any solution is not obvious (or breaks other workflows). My take: NAB