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
already broken in Build ID: 35913b9-4eb4f62-260b7c1 (around August 19) is ok in LibreOffice 343
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).
[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.
Created attachment 51908 [details] sample document, see Comment 3
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
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.
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 ;-) )
*** Bug 42031 has been marked as a duplicate of this bug. ***
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.
This is the result of a patch for n#677811. The question is what should this patch fix
@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?
Maybe we could shrink the data while pasting into non-calc places? (like writer or email clients or notepads?)
*** Bug 44022 has been marked as a duplicate of this bug. ***
Need to comment that this bug actually makes spreadsheet to hang.
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?
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.
(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.
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"
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.
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?
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?
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.
(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.
Working with LibO 3.5.1.2 on Win7 x64 SP 1 Changed status to "WORKSFORME"
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.
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)).
I confirm that it's OK in 3.5.2.2 and Master (2012-03-26) thanks!