Bug 109299 - Empty cells are not copied to external application like Notepad (while copied to another spreadsheet)
Summary: Empty cells are not copied to external application like Notepad (while copied...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
Keywords: notBibisectable, regression
: 118163 127600 (view as bug list)
Depends on:
Blocks: Paste
  Show dependency treegraph
Reported: 2017-07-24 08:00 UTC by Larsen
Modified: 2020-04-05 05:34 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Example (7.74 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-07-24 08:00 UTC, Larsen
sample data (8.48 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-06-26 10:25 UTC, Nelson

Note You need to log in before you can comment on or make changes to this bug.
Description Larsen 2017-07-24 08:00:28 UTC
Empty cells leading other data cells are not copied to an external application.

Steps to Reproduce:
1. Open attached example
2. Copy A1 to A5
3. Paste it into Notepad

Actual Results:  
Only the cells containing data are copied.

Expected Results:
Every cell should be copied including empty ones.

Reproducible: Always

User Profile Reset: No

Additional Info:

User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.112 Safari/537.36 Vivaldi/1.92.894.3
Comment 1 Larsen 2017-07-24 08:00:40 UTC
Created attachment 134809 [details]
Comment 2 Xavier Van Wijmeersch 2017-07-24 11:35:22 UTC
I think this is a normal behavior, its more the internal interpretation of how to ad data between to different applications. But this is more a guess than, but empty cells are empty and so there is nothing to copy
Comment 3 Larsen 2017-07-24 11:56:47 UTC
Those empty cells are copied when they are copied over other cells (inside LibreOffice), so they should also be copied to external applications.

Also, I noticed this bug when I was comparing data (in a text editor) between two documents. The data seemed to differ until I noticed that the second one was offset because of the missing cells at the top.
Comment 4 raal 2017-07-28 20:02:48 UTC
Reproducible. Marking as new, because empty cell between rows is copied:


repro with
Note: copy from excel->notepad works as reporter wants.
Comment 5 raal 2018-06-14 16:36:17 UTC
*** Bug 118163 has been marked as a duplicate of this bug. ***
Comment 6 ajev.removic 2018-06-14 16:49:28 UTC
(In reply to Xavier Van Wijmeersch from comment #2)
> I think this is a normal behavior, its more the internal interpretation of
> how to ad data between to different applications. But this is more a guess
> than, but empty cells are empty and so there is nothing to copy

Well, if I copied 5 rows, I expect to paste 5 lines, right?
Comment 7 QA Administrators 2019-06-15 02:59:37 UTC Comment hidden (obsolete)
Comment 8 Larsen 2019-06-18 09:13:55 UTC
Still a problem.

Version: (x64)
Build-ID: 2412653d852ce75f65fbfa83fb7e7b669a126d64
Comment 9 Nelson 2019-06-26 10:25:59 UTC
Created attachment 152412 [details]
sample data
Comment 10 Nelson 2019-06-26 10:35:28 UTC
Comment on attachment 152412 [details]
sample data

This absolutely is not a normal behaviour. Imagine that a set of data that has been nicely prepared in Libre Calc (with leading empty cell) was then pasted to an external application. It could lead to data inconsistency or error.

To reproduce, in my attachment copy cells A2 to C4 and paste to notepad. The result in notepad would look like there was no A column in the spreadsheet.

Unlike Libre, Ms Office got it right by copying all cells including empty ones.
Comment 11 Xisco Faulí 2019-10-03 11:10:55 UTC
*** Bug 127600 has been marked as a duplicate of this bug. ***
Comment 12 Timur 2019-10-03 11:47:02 UTC
Repro LO 6.4+. But this used to work as requested in LO 3.4. I'll mark regression from LO 3.5. Previously bibisect was available only from 3.6.
Comment 13 Timur 2020-02-21 14:52:11 UTC
Xisco, how do I check source commits for this one?


git bisect log
# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# skip: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect skip e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
git bisect good d1cca78ab77d64482b6643bc643d29dbe2dd1442
# good: [d1cca78ab77d64482b6643bc643d29dbe2dd1442] source-hash-2d19e9bb07ccff3134f855812dddfda5c07b1fe4
git bisect good d1cca78ab77d64482b6643bc643d29dbe2dd1442
# skip: [9daa289e178460daaafa4b3911031df5b8736218] source-hash-704292996a3731a61339b1a4a5c90c9403aa095f
git bisect skip 9daa289e178460daaafa4b3911031df5b8736218
# skip: [387dd1052972d27a3065a249b357e50e0a29829b] source-hash-35836f350861b33a0c28307a413eff76d0433d1e
git bisect skip 387dd1052972d27a3065a249b357e50e0a29829b
# skip: [19604661a278cb5b1b513d5bcf9e12eb85f4715f] source-hash-f05861de995f8d4edb1a97c616d050f55ec04c32
git bisect skip 19604661a278cb5b1b513d5bcf9e12eb85f4715f
# bad: [4d8d18a8c871d6803af99b706f780eb6e65c7a5d] source-hash-d4779887636fa9ab5b477f3436bcd3728a3e30ba
git bisect bad 4d8d18a8c871d6803af99b706f780eb6e65c7a5d
# bad: [66d8f76eaad7a1835bf0a828fb396b58b8f9dbaa] source-hash-21dd191b9fd5a75f7633ea27f745a347adb42ae3
git bisect bad 66d8f76eaad7a1835bf0a828fb396b58b8f9dbaa
# bad: [9236fd0352a4a587faac6f15f6b3b5331301380f] source-hash-250feedd8e50e5eb52682a194823567ba5287c60
git bisect bad 9236fd0352a4a587faac6f15f6b3b5331301380f
# bad: [a9ee9b23482f56e6b5626603c507aef2bb1bcc5d] source-hash-8b55ef8898a39803e9c4a8cd6a271576389c0249
git bisect bad a9ee9b23482f56e6b5626603c507aef2bb1bcc5d
# good: [bf468d032342783bc2ae3f8be5de91a8f073c137] source-hash-558b5ea32a99654dcb63526f107726f7aec4747f
git bisect good bf468d032342783bc2ae3f8be5de91a8f073c137
# bad: [7a864e30bffdf16060a3e8abe6d1f6853e841ce7] source-hash-4ff7252375b7b85eafbf176ca4e9184cc392d980
git bisect bad 7a864e30bffdf16060a3e8abe6d1f6853e841ce7
# good: [9300cbe83880d09cc6d581eb73a92f35f3456b31] source-hash-43c7830b03d141ae11d8617c0fdabefa32dd243c
git bisect good 9300cbe83880d09cc6d581eb73a92f35f3456b31
# bad: [1a3c4b54a8782fe0f4bdba221e87012a92e4d323] source-hash-a330f38093e2643a26239557050561afae9ff23d
git bisect bad 1a3c4b54a8782fe0f4bdba221e87012a92e4d323
# bad: [d202b17d88ecb0b608d81518624021c832c7dfdb] source-hash-ce97851773a06103504972eb2771eecd7dd81e36
git bisect bad d202b17d88ecb0b608d81518624021c832c7dfdb
# first bad commit: [d202b17d88ecb0b608d81518624021c832c7dfdb] source-hash-ce97851773a06103504972eb2771eecd7dd81e36

d202b17d88ecb0b608d81518624021c832c7dfdb is the first bad commit
commit d202b17d88ecb0b608d81518624021c832c7dfdb
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Wed Apr 25 07:28:24 2012 +0200

    commit ce97851773a06103504972eb2771eecd7dd81e36
    Author:     David Tardon <dtardon@redhat.com>
    AuthorDate: Mon Feb 6 19:12:02 2012 +0100
    Commit:     David Tardon <dtardon@redhat.com>
    CommitDate: Mon Feb 6 19:12:02 2012 +0100
        fix typo

:100644 100644 e1c1d62aa980fee004430f920cdbe3fd1ce79bf0 9acf11b8f6f5e26b03649767813ac42f72c38e1b M	autogen.log
:100644 100644 c14237a7b6ebde67a83585c9b057c78710e08ea2 db4232175b715b6c7f322b17041f56a9145e1622 M	ccache.log
:100644 100644 c407d12366338584cbcebf2197cd7fcdcf1c522b 1b83a94159f8aa22e004b5dc2ebe1895b32a2724 M	commitmsg
:100644 100644 3be616510b5296b5ae2f5c154a6c51f7ba49bf24 cc9f341a09ba536bb41d4219c5b7f5dd219d7cc6 M	dev-install.log
:100644 100644 637e789a93608b99c13fec9e598c2e7a4c454c6d 08ab33c46c34b7b9b0f8b7f21161ad1c1a2ed59a M	make.log
:040000 040000 c47ba9e6977c3c8a957b11ec3f8b85cfa50362af f87831ea583aaccb888e681ce264cc1e4e44d3aa M	opt

Comment 14 Timur 2020-02-21 16:12:22 UTC
Correction: 43all
Comment 16 Aron Budea 2020-04-05 05:34:18 UTC
(In reply to Timur from comment #15)
> This should be the range:
> https://cgit.freedesktop.org/libreoffice/core/log/
> ?qt=range&q=43c7830b03d141ae11d8617c0fdabefa32dd243c..
> ce97851773a06103504972eb2771eecd7dd81e36
> Not obvious which is the commit.
The range covers several months, so unfortunately not very helpful (but can't be helped, that's the granularity of this particular commit in the bibisect repo). Additionally, if the exact commit isn't identified, the usage of bisected keyword isn't warranted. Setting to notBibisectable instead.