Bug 79395 - Grid lines messed up when editing certain spreadsheet file
Summary: Grid lines messed up when editing certain spreadsheet file
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
(earliest affected) release
Hardware: All All
: highest normal
Assignee: Not Assigned
Keywords: bibisected, bisected, regression
: 89211 91156 (view as bug list)
Depends on:
Blocks: mab4.3
  Show dependency treegraph
Reported: 2014-05-29 07:39 UTC by Kevin Suo
Modified: 2016-01-20 10:15 UTC (History)
12 users (show)

See Also:
Crash report or crash signature:

Test xlsx file (9.94 KB, application/vnd.openxmlformats-officedocument.spreadsheetxml)
2014-05-29 07:39 UTC, Kevin Suo
test ods file (11.96 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-07-19 09:12 UTC, Kevin Suo
Details screenshot (90.17 KB, image/png)
2014-07-19 09:13 UTC, Kevin Suo
another easy test file (20.25 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-10-27 03:21 UTC, Kevin Suo

Note You need to log in before you can comment on or make changes to this bug.
Description Kevin Suo 2014-05-29 07:39:18 UTC
Created attachment 100083 [details]
Test xlsx file

Decription: When open the attached simple xlsx file with calc, grid line is massed up. Clicking between cells makes it even worse. Scrolling up and down will make it back to normal again.

1. Open the attached xlsx file; (grid lines are massed up a little bit)
2. Click between cells; (this makes the mass-up even worse)
3. Scrolling up and down. (This will bring it back to normal)

OS: Both tested and reproduce on Windows XP X86 SP3 and Fedora 20 x64
LibreOffice Versions: Reproduce with,, and 4.3.0 beta 1.
Comment 1 Yousuf Philips (jay) (retired) 2014-05-29 07:45:25 UTC
Confirmed in Linux Mint with 4.2.4, 4.2.6 and 4.3 beta. It doesnt effect 3.6 and 4.0 as the row isnt shrunk and with 4.1 the row is shrunk but it looks perfect. So regression it is.
Comment 2 Kevin Suo 2014-05-29 07:52:46 UTC
Just for information: 

Cell A1 was formatted as "[DBNum2]" number format when I was testing the "[DBNumX]" and "[NatNumX]" bug.
LibreOffice did not import the "[DBNum2]" formatting, it only recongnize [NatNumX]". (This will be filed in another bug report)
Comment 3 yanjingtao 2014-05-29 09:00:24 UTC
Reproducible with 

OS:Fedora 20 x86_64
Build ID:

OS:Fedora 20 x86_64
Build ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f

OS:Windows XP SP3
Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
Comment 4 Kohei Yoshida 2014-05-29 16:03:04 UTC
massed up -> messed up
Comment 5 Joel Madero 2014-06-18 05:33:47 UTC
 5023c3e436e8a445b700a81bd4a404673084678a is the first bad commit
commit 5023c3e436e8a445b700a81bd4a404673084678a
Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com>
Date:   Sun May 11 02:08:49 2014 +0000

    commit 5da974369d01760b336de34e68c03d7268d2d330
    Author:     Jan-Marek Glogowski <glogow@fbihome.de>
    AuthorDate: Tue Dec 24 19:47:30 2013 +0100
    Commit:     Michael Stahl <mstahl@redhat.com>
    CommitDate: Wed Jan 15 11:16:17 2014 +0000
        Rename some mail merge variables
        Fixes the variable name typo pSourrceDocSh and renames bLoop to
        bNoError to represent the variables function.
        Change-Id: Iba688ed0fb40c0c3947da1b21beb00c67a10ff09
        Reviewed-on: https://gerrit.libreoffice.org/7431
        Reviewed-by: Michael Stahl <mstahl@redhat.com>
        Tested-by: Michael Stahl <mstahl@redhat.com>

:100644 100644 4acfb86899baca0ec86fa23cb64192f49c9ea53f 3e197ed074c9d37c20514d7ad671bb9b14fc9e43 M	ccache.log
:100644 100644 450159a287e79f7c7452d5e3ac79033e5902be24 8b7fb2264ddbbe0b6ce62df55df3cc17d4094fcb M	commitmsg
:100644 100644 694263ae1a06fc1dd8e7bc925cb5b4d5b9d5a2d2 ec16c05dc4818fa880ea7db9663c1512dc9f2a7b M	make.log
:040000 040000 75aa68adda2226c2263e017bddbf8af0bc19ae25 5a80d6cbdd314c2de7ed5961665c1af9f4a4b053 M	opt

# bad: [423a84c4f7068853974887d98442bc2a2d0cc91b] source-hash-c15927f20d4727c3b8de68497b6949e72f9e6e9e
# good: [65fd30f5cb4cdd37995a33420ed8273c0a29bf00] source-hash-d6cde02dbce8c28c6af836e2dc1120f8a6ef9932
git bisect start 'latest' 'oldest'
# good: [e02439a3d6297a1f5334fa558ddec5ef4212c574] source-hash-6b8393474974d2af7a2cb3c47b3d5c081b550bdb
git bisect good e02439a3d6297a1f5334fa558ddec5ef4212c574
# good: [4850941efe43ae800be5c76e1102ab80ac2c085d] source-hash-980a6e552502f02f12c15bfb1c9f8e6269499f4b
git bisect good 4850941efe43ae800be5c76e1102ab80ac2c085d
# skip: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
git bisect skip a900e72b6357882284c5955bdf939bf14269f5fb
# skip: [3dda83fc3a43afc6af7f5c0ffd029e610ec1b9a3] source-hash-c59b3d6c5c8096486730007d9b9b053793b90b1e
git bisect skip 3dda83fc3a43afc6af7f5c0ffd029e610ec1b9a3
# bad: [4f705a8cfb1998b09f2062510b207d35a33647d8] source-hash-1eeb20f3958666ec6ba6e0fcf52e92e5eb447a14
git bisect bad 4f705a8cfb1998b09f2062510b207d35a33647d8
# bad: [3c72d6d27e2a0c420f74941355400b0834c550bb] source-hash-c30677731c55688c764a669ecea1b1c4d17ae57d
git bisect bad 3c72d6d27e2a0c420f74941355400b0834c550bb
# bad: [92457a48f3715b1233ea025387627280dae681b0] source-hash-c1503da35d8879366da13258837cf0084a536809
git bisect bad 92457a48f3715b1233ea025387627280dae681b0
# skip: [bde12e7d6eef3d657ebdf62cb5442490fb90d899] source-hash-03725013b64e74473e1a9e925b24927e7e61d412
git bisect skip bde12e7d6eef3d657ebdf62cb5442490fb90d899
# bad: [0d4c20a601a3cfff27d6685d0e81463086bd9d74] source-hash-f1b1e73227471192682d303a58618ca8bd65a74d
git bisect bad 0d4c20a601a3cfff27d6685d0e81463086bd9d74
# bad: [77962b3d9a08d8c7177b2c67da6ed1c5bc26572c] source-hash-d1ba55a28cd40134356faf3e01971491086591d9
git bisect bad 77962b3d9a08d8c7177b2c67da6ed1c5bc26572c
# good: [6b545103ded12a7a1e7b490734eb094344a0f3ca] source-hash-76702bc75d79dee09a01c57c68e49efa5664c355
git bisect good 6b545103ded12a7a1e7b490734eb094344a0f3ca
# good: [08fb0779e12ba62d8ee44ef292e88d4c924c5742] source-hash-62d8fea76ed4f0c97c6ef2bb78228e5904b72be1
git bisect good 08fb0779e12ba62d8ee44ef292e88d4c924c5742
# bad: [5023c3e436e8a445b700a81bd4a404673084678a] source-hash-5da974369d01760b336de34e68c03d7268d2d330
git bisect bad 5023c3e436e8a445b700a81bd4a404673084678a
# first bad commit: [5023c3e436e8a445b700a81bd4a404673084678a] source-hash-5da974369d01760b336de34e68c03d7268d2d330
Comment 6 Kevin Suo 2014-07-19 09:12:16 UTC
Created attachment 103086 [details]
test ods file

Actually this bug affects all spreadsheet file types.

Steps to reproduce with this ods file:
1. Just click random cells in the sheet. (you have to click several cells in order to reproduce.
2. If you see the cell grid is abnormal, then double-click in cells will make it even worse.

Scrolling the sheet will bring it back to normal.

Still reproduce with, Ubuntu 14.04 x86.
Comment 7 Kevin Suo 2014-07-19 09:13:11 UTC
Created attachment 103087 [details] screenshot

See the grid lines... they are totally messed up.
Comment 8 Kevin Suo 2014-10-27 03:21:08 UTC
Created attachment 108486 [details]
another easy test file

The attached .ods file has a long string in B3. You can observe this problem more clealy following these steps:

1. Open the attached ods file;
2. Set column width of Column B to "1cm", then click any other cells.
--> Grid lines are messed up.
3. Scroll up and down, grid lines will be OK now.
4. Set column width of Column B to "5cm", then click any other cells.
--> Grid lines messed up again.
5. Scrolling up and down, grid lines will be OK again.

It seem that grid lines are not updated after row height are automically adjusted.
Comment 9 Kevin Suo 2014-10-27 03:23:03 UTC
Adding to MAB4.2 list
Comment 10 Kevin Suo 2014-11-07 05:55:15 UTC
A quick look at this range (the last good and bad):


This one is the most suspicious: bbdb7b43e639b0dd27377d104c59fea3f8481b2a

author:	Michael Meeks <michael.meeks@collabora.com>	2014-01-06 22:03:45 (GMT)
committer: Michael Meeks <michael.meeks@collabora.com>	2014-01-14 15:52:14 (GMT)
commit: bbdb7b43e639b0dd27377d104c59fea3f8481b2a (patch)
tree: 3b370423c8b36d32451e6e58ff7ca651003d93cc
parent: 91570fc3f37bedd66eb11b7fb585e207e51abeaa (diff)

sc: re-work ScHorizontalCellIterator to try to improve performance.

Add more unit tests, reduce the number of rows that we know are empty that we iterate over while saving by shrinking the column set that we scan as we go along. 

Change-Id: Iebd817d9a8a01fa6abeaa24c4aace92233313e0f
Comment 11 tommy27 2014-12-05 20:56:10 UTC
still reproducible with LibO and
Build ID: f20043a0805c3a75eb4024ed59f45291aea93ac0
TinderBox: Win-x86@39, Branch:master, Time: 2014-12-03_01:16:50

moving this buig to mab4.3 list since 4.2.x is END OF LIFE
Comment 12 Matthew Francis 2015-01-16 02:48:30 UTC
In fact it seems that the visual corruption starts at the below commit.

commit df9243626b39742a9a148bea95796f8824fee68a
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Tue Jan 14 10:55:02 2014 -0500

    fdo#73606: Avoid excessive and unnecessary heap allocation of array objects.
    This is a leftover from the 1 million row conversion we did years ago.
    Change-Id: Ib50819ed51c7017bcc559bfc8b6062ff46615d09
Comment 13 Vladimir 2015-02-08 21:02:34 UTC
*** Bug 89211 has been marked as a duplicate of this bug. ***
Comment 14 raal 2015-05-11 18:24:24 UTC
*** Bug 91156 has been marked as a duplicate of this bug. ***
Comment 15 Kevin Suo 2015-06-23 09:32:32 UTC
I tested and confirm that this bug does not reproduce with version:
Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e
Locale: zh-CN (zh_CN)

I also do not reproduce bug 91156 with this version.

It may be fixed by some commit. Since we do not know the exact commit number, I mark this bug as RESOLVED WORKSFORME.
Comment 16 Robinson Tryon (qubit) 2015-12-15 11:03:11 UTC
Migrating Whiteboard tags to Keywords: (bibisected)