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)
Version:
(earliest affected)
3.5.0 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: notBibisectable, regression
: 118163 127600 (view as bug list)
Depends on:
Blocks: Paste
  Show dependency tree / graph
 
Reported: 2017-07-24 08:00 UTC by Larsen
Modified: 2024-04-08 09:22 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:

Attachments
Example (7.74 KB, application/vnd.oasis.opendocument.spreadsheet)
2017-07-24 08:00 UTC, Larsen 		Details
sample data (8.48 KB, application/vnd.oasis.opendocument.spreadsheet)
2019-06-26 10:25 UTC, Nelson 		Details
View All Add an attachment (proposed patch, testcase, etc.)

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 
Description:
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]
Example
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:
1
2
3

4


repro with 4.2.8.2
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: 6.2.4.2 (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 Comment hidden (obsolete)
Comment 14 Timur 2020-02-21 16:12:22 UTC Comment hidden (obsolete)
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.
Comment 17 QA Administrators 2022-04-06 03:45:06 UTC Comment hidden (obsolete)
Comment 18 Larsen 2022-04-06 09:49:52 UTC 
Still a problem in 7.3.2.2 (x64)
Comment 19 Timur 2022-04-06 13:23:05 UTC 
Xisco, when building, can you try with a commit I wrote or maybe some probable?
Comment 20 QA Administrators 2024-04-06 03:15:02 UTC Comment hidden (obsolete)
Comment 21 Larsen 2024-04-08 09:22:06 UTC 
Still a problem in 7.6.6.3