Bug 40958 - EDITING: Copy row to clipboard incomplete ... or: pasting copied row to other rows, makes that data in that row is repeated until the last column
Summary: EDITING: Copy row to clipboard incomplete ... or: pasting copied row to other...
Status: CLOSED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Master old -3.6
Hardware: Other All
: medium major
Assignee: Markus Mohrhard
URL:
Whiteboard: target:3.5.0
Keywords: regression
: 42031 44022 (view as bug list)
Depends on:
Blocks: mab3.5
  Show dependency treegraph
 
Reported: 2011-09-17 01:08 UTC by Cor Nouws
Modified: 2012-04-04 09:09 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
sample document, see Comment 3 (8.86 KB, application/vnd.oasis.opendocument.spreadsheet)
2011-10-03 11:14 UTC, Rainer Bielefeld Retired
Details
New Sample (9.28 KB, application/vnd.oasis.opendocument.spreadsheet)
2012-03-19 08:19 UTC, Rainer Bielefeld Retired
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cor Nouws 2011-09-17 01:08:26 UTC
Found in Build ID: 91a7e5a-3dca5fd-da627d2

- start spreadsheet
- type starting in B1 e.g 
Mango
Melon
Pear
Apple
Grape
Kiwi fruit
Orange

- Select row 4 (Shft-Space)
- Copy (Ctrl-C)
- Insert row (Ctrl-+)
- Paste (Ctrl-V)
 > Apple in each cell on row 4

Expected: Apple in Colum B only
Comment 1 Cor Nouws 2011-09-17 01:14:41 UTC
already broken in Build ID: 35913b9-4eb4f62-260b7c1 (around August 19)
is ok in LibreOffice 343
Comment 2 Julien Nabet 2011-09-17 15:59:55 UTC
I've got exactly the same behavior on master updated today on Debian Linux (pc x86).
I've got no message on console (debug/warning/error).
Comment 3 Rainer Bielefeld Retired 2011-10-03 11:13:23 UTC
[Reproducible] with Server installation of Master "LibO-dev 3.5.0 – WIN7 Home Premium (64bit) English UI [(Build ID: 81607ad-3dca5fd-da627d2)]"

I tested with attached Test document. The mishap starts already with <Control+C>.
Proceeding due to original report you will see the dotted flickering line only around the "Apple", what means only that is the clipboard contents. That's the problem!

With this clipboard contents the Paste-behavior is intended. There i no need to insert line or similar, that's only a way to get a whole row for paste selected. you get the same effect selecting Row 20 with a click on the row Header.

Some further investigations with original sample0.ods:

11. Type "x" to 'F15'
12. Select row 4 by click on row header
13. <Contro+C>
    expected: dotted flickering line around all row 4
    actual: dotted flickering line around B4:F4
14. Select row 14 by click on row header
15. <Contro+V>
    The clipboard contents will be pasted correctly with "apple in A12, F12, 
    K12 ...

My Conclusion:
Only cell contents from cells of the row area with contents somewhere in the columns in any row) will be copied to clipboard.

@Kohei:
Please feel free to reassign (or reset Assignee to default) if it’s not your area. Please set Status to ASSIGNED if you accept this Bug.
Comment 4 Rainer Bielefeld Retired 2011-10-03 11:14:08 UTC
Created attachment 51908 [details]
sample document, see Comment 3
Comment 5 Cor Nouws 2011-10-17 04:00:42 UTC
Also with Experimental features turned off, this big exists in Build ID: 4456143-f6a1fc5-e1a2fb3

Now, the repetition starts at the end of the data range 
(last column with data, in example below, x is data in a cel)


x   x   x   x   x   x   x

AA
BB
CC
CC                        CC                        CC      
DD
Comment 6 Markus Mohrhard 2011-11-08 10:10:59 UTC
I'll have a look at it.

I think that is a bug from a change in our copy handling. We now only copy the needed cells to our copy document while in our old copy handling we copied all cells. I need to think about a fix for that problem.
Comment 7 Cor Nouws 2011-11-09 08:38:26 UTC
Hi Markus,
Thanks!
I noted that it goes fine as long as the row contains a continues range.
The error shows when some cells in between are empty.
(Hope this is clear enough ;-) )
Comment 8 Markus Mohrhard 2011-12-16 16:52:46 UTC
*** Bug 42031 has been marked as a duplicate of this bug. ***
Comment 9 Markus Mohrhard 2011-12-17 16:41:30 UTC
Need to look into that for beta2.

I suspect it is a problem with our new ShrinkToUsedArea approach for copying to our copy document. Then while copying to our target document we no longer know that we selected a much larger area and try to autofill the remaining cells.

Maybe we should just save in the copy document the old copy range and determine our paste behavior depending on this value instead of the shrunken area.

Need to investigate that a bit. I hope I have some time to fix it for beta2.
Comment 10 Markus Mohrhard 2011-12-18 21:24:44 UTC
This is the result of a patch for n#677811. The question is what should this patch fix
Comment 11 Muthu 2011-12-18 22:38:39 UTC
@moggi: Thank you for the ping :)

Some background: The behaviour was modified a little to not copy the entire block of data, but only the cells which have data. [You could see this when you press Ctrl+C the dotted moving lines are only over those cells - in this case 'Apple']
So, when you paste, it behaves as though you had copied one cell and pasting it over a range of cells.

The problem with the original behaviour: When pasting into Mail clients like outlook, blank data is unnecessarily pasted - which doesn't make sense. Most, importantly it causes unreadable data paste on clients like Outlook.
[Also, the higher mem. usage for storing blank data]

The question is what would be a better acceptable way, if this is a problem. Maybe one for UX team to decide?
Comment 12 Muthu 2011-12-18 22:44:41 UTC
Maybe we could shrink the data while pasting into non-calc places?
(like writer or email clients or notepads?)
Comment 13 Markus Mohrhard 2011-12-21 17:53:31 UTC
*** Bug 44022 has been marked as a duplicate of this bug. ***
Comment 14 izapolsky 2011-12-22 02:39:13 UTC
Need to comment that this bug actually makes spreadsheet to hang.
Comment 15 Markus Mohrhard 2011-12-23 00:13:51 UTC
I think I finally have a correct patch that shows preserve the old copy paste behavior for calc internal copy/paste while it still has the advantage that it only copies the relevant entries to other programs.

@Muthu: can you check that your bug is still fixed in master and 3-5?
Comment 16 Rainer Bielefeld Retired 2012-03-19 05:08:26 UTC
This is not fixed in "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit).
Problem with 3.5.0RC2, too.
Comment 17 Markus Mohrhard 2012-03-19 08:06:07 UTC
(In reply to comment #16)
> This is not fixed in "LibreOffice 3.5.1.2 German UI/Locale [Build-ID:
> dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit).
> Problem with 3.5.0RC2, too.

Can you please explain what you see? In my 3-5 build copy/paste is working correctly. If you are refering to the Drag and Drop problem then this is a different bur related problem.
Comment 18 Rainer Bielefeld Retired 2012-03-19 08:19:59 UTC
Created attachment 58690 [details]
New Sample

Its exactly the reported problem. My proceeding to get result like shown in row 10 with  "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66] on German WIN7 Home Premium (64bit):

1. Open sample11.ods
2. Click row header "5" 
   > complete row selected
3. <control+c> for copy
4. Click row header "20"
   > complete row 20 selected
5. <control+c> for paste
   Expected: "Grape" in B20
   Actual: all cells A20:AMJ20 with "Grape"
Comment 19 Rainer Bielefeld Retired 2012-03-19 08:53:35 UTC
Problem persists with new profile.
Even worse: when in step 4 into cell A20, "Grape" will be pasted into A20 instead B20. Strange: I can't reproduce with 3.5.0 on WIN XP32 WirtualBox, I will do further investigation.
Comment 20 Rainer Bielefeld Retired 2012-03-19 09:17:35 UTC
Remains not reproducible on WIN XP 32Bit VirtualBox after update to "LibreOffice 3.5.1.2 German UI/Locale [Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66]"
Sigh - Markus, any ideas what I still should compare?
Comment 21 Rainer Bielefeld Retired 2012-03-19 09:23:07 UTC
I checked some more Server installations including Master 3.6 (some old) on my Win7 64bit, all show the problem. Is it possible that that's a WIN7 or 64Bit problem?
Comment 22 Markus Mohrhard 2012-03-19 09:24:36 UTC
Will check with your document later.

I don't think that this can happen and I haven't seen this problem for some time in master/3-5. Maybe you executed some special code paths that were using the DnD code and not the copy/paste code but I need to check with an up-to-date 3-5 build.
Comment 23 Markus Mohrhard 2012-03-19 09:25:49 UTC
(In reply to comment #21)
> I checked some more Server installations including Master 3.6 (some old) on my
> Win7 64bit, all show the problem. Is it possible that that's a WIN7 or 64Bit
> problem?

Normally not. Copy/pasting inside calc should not use any parts of the system clipboard but will try to reproduce it. If it is really a windows problem I will ask Kohei to check.
Comment 24 Florian Reisinger 2012-03-19 10:09:34 UTC
Working with LibO 3.5.1.2 on Win7 x64 SP 1

Changed status to "WORKSFORME"
Comment 25 Rainer Bielefeld Retired 2012-03-19 12:06:40 UTC
Not reproducible on a second WIN7 64 Bit machine, but that one is not affected by "Bug 43989 - After installation first launch terminates after splash screen" - there CAN be exotic effects.

This bug can't be WFM. It's 
a) FIXED if my problem is only related to my PC or the problem has similar symptoms like the problem from report, but different roots,   or it's 
b) REOPENED if the problem really appeared again.

Currently I believe it's 'a', for example because the observed behavior differs from Comment 3 Step 13

So I believe I will open a new bug for this after some more research.
Comment 26 Roman Eisele 2012-03-20 00:04:50 UTC
Just for the record:
To test yet another platform, I tried to repoduce the bug on MacOS X 10.6.8 with LibreOffice 3.5.1.2 (Build-ID: dc9775d-05ecbee-0851ad3-1586698-727bf66). But both the steps given by Cor Nouws in his initial description and by Rainer Bielefeld (comment #18) don’t show the bug anymore: everything works as expected.

This may confirm that Rainer Bielefeld’s thesis a), as given in comment #25, is the right one (not thesis b)).
Comment 27 Cor Nouws 2012-04-04 09:09:52 UTC
I confirm that it's OK in 3.5.2.2 and Master (2012-03-26)
thanks!