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. Steps: 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 4.2.4.2, 4.2.5.1, and 4.3.0 beta 1.
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.
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)
Reproducible with OS:Fedora 20 x86_64 Version: 4.2.4.2 Build ID: 4.2.4.2-8.fc20 OS:Fedora 20 x86_64 Version: 4.3.0.0.beta1 Build ID: 2e39c7e59c8fc8b16a54c3d981dceef27fb0c07f OS:Windows XP SP3 Version: 4.2.4.2 Build ID: 63150712c6d317d27ce2db16eb94c2f3d7b699f8
massed up -> messed up
5023c3e436e8a445b700a81bd4a404673084678a is the first bad commit commit 5023c3e436e8a445b700a81bd4a404673084678a Author: Bjoern Michaelsen <bjoern.michaelsen@canonical.com> Date: Sun May 11 02:08:49 2014 +0000 source-hash-5da974369d01760b336de34e68c03d7268d2d330 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
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 4.3.0.3, Ubuntu 14.04 x86.
Created attachment 103087 [details] 4.3.0.3 screenshot See the grid lines... they are totally messed up.
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.
Adding to MAB4.2 list
A quick look at this range (the last good and bad): http://cgit.freedesktop.org/libreoffice/core/log/?qt=range&q=5da974369d01760b336de34e68c03d7268d2d330...62d8fea76ed4f0c97c6ef2bb78228e5904b72be1 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
still reproducible with LibO 4.3.4.1 and 4.5.0.0.alpha0+ 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
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
*** Bug 89211 has been marked as a duplicate of this bug. ***
*** Bug 91156 has been marked as a duplicate of this bug. ***
I tested and confirm that this bug does not reproduce with version: Version: 5.0.0.1 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.
Migrating Whiteboard tags to Keywords: (bibisected) [NinjaEdit]