Bug 118747 - Table paste from specific .ods to Writer adds two empty rows above so table looks emtpy
Summary: Table paste from specific .ods to Writer adds two empty rows above so table l...
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: framework (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha0+
Hardware: All All
: medium trivial
Assignee: Vasily Melenchuk (CIB)
URL:
Whiteboard: target:6.2.0 target:6.1.4
Keywords: bibisected, bisected, regression
Depends on:
Blocks:
 
Reported: 2018-07-13 16:09 UTC by Timur
Modified: 2018-10-30 03:57 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Timur 2018-07-13 16:09:35 UTC
While testing workaround for Bug 118676 with master 6.2+ I got this:

1. Open attachment 143433 [details] 
2. Copy some cells with data, enough is B:4
3. Paste in the same sheet, like in O:40
4. Copy that cell again
5. Open new Writer document
6. Paste (just ctrl+v)

Expected: only selected cell is pasted and visible
Experienced: visible cell is empty and pasted cell is two rows bellow

Doesn't happen with empty .ods from scratch, can't explain why.
Looks like a (recent) regression.
Comment 1 Jacques Guilleron 2018-07-14 08:11:29 UTC
Hi Timur,

I confirm with
LO 6.2.0.0.alpha0+ Build ID: 67c88e284af74c88e37cc8f66cdfc0e346de45ac
CPU threads: 2; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-06-19_23:41:55
Locale: fr-FR (fr_FR); Calc: CL
and upper versions.
I don't reproduce with
LO  6.2.0.0.alpha0+ Build ID: 7530424771c84d50f1e7e9ec5eba0bffc91d655a
CPU threads: 2; OS: Windows 6.1; UI render: default; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-06-06_05:38:42
Locale: fr-FR (fr_FR); Calc: CL
Same behavior when starting from scratch.
Comment 2 Xisco Faulí 2018-07-14 12:08:41 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=1e55a47e89a9d9d6cf9cb3993484022aaf2c097b

author	Vasily Melenchuk <Vasily.Melenchuk@cib.de>	2018-04-06 20:19:10 +0300
committer	Thorsten Behrens <Thorsten.Behrens@CIB.de>	2018-06-08 00:47:06 +0200
commit	1e55a47e89a9d9d6cf9cb3993484022aaf2c097b (patch)
tree	3a3372525645775c32721e59ce8c205c8f474ffd
parent	2a7f74900fb646235b74d4c9bd4690e44edc3ed4 (diff)
tdf#62268: allow row height recalculation on document load
During document load rows with style:use-optimal-row-height="true"
should recalculate it's height.


Bisected with: bibisect-linux64-6.2

Adding Cc: to Vasily Melenchuk
Comment 3 Commit Notification 2018-10-25 09:27:36 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=1b9574ed8269f4ed9dde33856c1d74702a7fa4bb

tdf#118747 sc: use manual height for previous rows in TransferObj

It will be available in 6.2.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 4 Timur 2018-10-26 16:48:45 UTC
Looks like I didn't write good steps (single cell needs Paste special as Spreadsheet, two cells can be pasted with Ctrl-V): 

1. Open attachment 143433 [details] 
2. Copy some cells with data, enough is A:4-B:4
3. Paste in the same sheet, like in H:20
4. Copy those cells H:20-I:20 again
5. Open new Writer document
6. Paste special as Spreadsheet.

Expected: only selected cell is pasted and visible
Experienced: visible cell is empty and pasted cell is two rows bellow
Experienced with fix: as expected

Anyway, it's OK. 
Vasily, is there any reason you didn't marked as Fixed?
Comment 5 Vasily Melenchuk (CIB) 2018-10-26 20:36:43 UTC
> Vasily, is there any reason you didn't marked as Fixed?

I planned to create a unit-test for this situation. Anyway it will be a next commit and bug is fixed from my POV.
Comment 6 BogdanB 2018-10-29 09:35:43 UTC
Solved. verified on:
Version: 6.2.0.0.alpha1+
Build ID: 3cccff0bbd17ecd4ce386c9eaea06bfa3d14115b
CPU threads: 4; OS: Linux 4.15; UI render: GL; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-10-27_16:28:45
Locale: en-US (ro_RO.UTF-8); Calc: threaded
Comment 7 Xisco Faulí 2018-10-29 16:48:23 UTC
Verified in

Version: 6.2.0.0.alpha1+
Build ID: 19a0698079fbba36646a2d06eaec3a7fde60b2f5
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded

@Vasily Melenchuk, Thanks for fixing this one!!

Since 
https://cgit.freedesktop.org/libreoffice/core/commit/?id=1e55a47e89a9d9d6cf9cb3993484022aaf2c097b is in 6.1.4 I've cherry-picked the commit fixing this issue to 6.1 branch -> https://gerrit.libreoffice.org/#/c/62518/
Comment 8 Commit Notification 2018-10-30 03:57:51 UTC
Vasily Melenchuk committed a patch related to this issue.
It has been pushed to "libreoffice-6-1":

https://git.libreoffice.org/core/+/968fac07d5e70c198459581f51e88179d3940d8a%5E%21

tdf#118747 sc: use manual height for previous rows in TransferObj

It will be available in 6.1.4.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.