Bug Hunting Session
Bug 77592 - FILEOPEN: LibO 4.2.x incorrectly changes row height
Summary: FILEOPEN: LibO 4.2.x incorrectly changes row height
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.1.1 release
Hardware: All All
: highest normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
: 80059 (view as bug list)
Depends on:
Blocks: mab4.3
  Show dependency treegraph
 
Reported: 2014-04-17 19:58 UTC by rlk
Modified: 2015-12-15 11:03 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Spreadsheet demonstrating problem of row expanding in height. (608.31 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-04-17 19:58 UTC, rlk
Details
Screenshot showing incorrect row indices (101.17 KB, image/png)
2015-01-16 14:19 UTC, rlk
Details

Note You need to log in before you can comment on or make changes to this bug.
Description rlk 2014-04-17 19:58:47 UTC
Created attachment 97531 [details]
Spreadsheet demonstrating problem of row expanding in height.

Problem description: Opening the attached spreadsheet, I find that some rows on sheet1 expand from 0.10" to 0.18" height.  This does not occur with LibreOffice 4.1.5.3 (and earlier); I have observed it with all 4.2 releases I have been able to try (4.2.2.1 and 4.2.3).  This is using either the OpenSUSE RPMs or the LibreOffice ones (for 4.2; for 4.1.5.3, I've only used the openSUSE ones).

Steps to reproduce:
1. Open the attached spreadsheet

Current behavior: Row 1627 grows from 0.1" to 0.18" height, and the row indices below 1627 are incorrect until the cursor is moved into a cell on that row.

Expected behavior: All rows (other than row 1) in sheet1 are 0.1" in height.

              
Operating System: openSUSE
Version: 4.2.2.1 release
Last worked in: 4.1.5.3 release
Comment 1 tommy27 2014-04-23 15:23:24 UTC
I confirm regression under Win7x64 using 4.2.3.3
Row 1627 grows looks larger in that release whilst it looks normal in 4.1.5.3
Comment 2 rlk 2014-04-24 00:38:55 UTC
I believe I've seen it in cases other than just opening a file using the openSUSE RPM's, although I wasn't able to find another case using the OEM ones.
Comment 3 rlk 2014-05-23 19:35:02 UTC
Still present in 4.2.4.
Comment 4 Xisco Faulí 2014-06-12 13:14:43 UTC
bibisected:

There are only 'skip'ped commits left to test.
The first bad commit could be any of:
c9046ea7e069426d10e071d0bcb01c64685844c6
2d8ee8e5bf8901874460df1b36b3faceae1cb931
We cannot bisect more!

# 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
# bad: [a900e72b6357882284c5955bdf939bf14269f5fb] source-hash-dd1050b182260a26a1d0ba6d0ef3a6fecc3f4e07
git bisect bad a900e72b6357882284c5955bdf939bf14269f5fb
# bad: [e1d0365cd2b073a859f59ad0a4584385a66dc611] source-hash-2eea96c702a44ab009743b0d22ef639127f0b57b
git bisect bad e1d0365cd2b073a859f59ad0a4584385a66dc611
# good: [98a55bf95f3ec29298751fd8fba76dd2236dce43] source-hash-58dfc97ca697875c36b7ddf14f5505a93d7b9cf8
git bisect good 98a55bf95f3ec29298751fd8fba76dd2236dce43
# bad: [1f32fb58159d7f43a4bcb838765261d5274cbf38] source-hash-4a169e4203c10ec8f76b9bcb33882c82b65c7bab
git bisect bad 1f32fb58159d7f43a4bcb838765261d5274cbf38
# good: [2a073e18fe4a9176dd35e962655ebf05a1e8d1b9] source-hash-4e938c468a1d1b6e93a4e468bbfe2f4270e37c4b
git bisect good 2a073e18fe4a9176dd35e962655ebf05a1e8d1b9
# good: [e2ef0c10eb06304986b8503584b44f02561ce4b5] source-hash-1b4aadebeb1898686313ff30ef47ddc4336a7444
git bisect good e2ef0c10eb06304986b8503584b44f02561ce4b5
# bad: [2d8ee8e5bf8901874460df1b36b3faceae1cb931] source-hash-777e3930a1e85b9bc97c1852b09802fc389c5e2d
git bisect bad 2d8ee8e5bf8901874460df1b36b3faceae1cb931
# skip: [c9046ea7e069426d10e071d0bcb01c64685844c6] source-hash-f5115e33e4c5e49e9b79ed32fccc193a99c3dc30
git bisect skip c9046ea7e069426d10e071d0bcb01c64685844c6
# only skipped commits left to test
# possible first bad commit: [2d8ee8e5bf8901874460df1b36b3faceae1cb931] source-hash-777e3930a1e85b9bc97c1852b09802fc389c5e2d
# possible first bad commit: [c9046ea7e069426d10e071d0bcb01c64685844c6] source-hash-f5115e33e4c5e49e9b79ed32fccc193a99c3dc30
Comment 5 rlk 2014-06-25 19:36:50 UTC
Still in 4.3.0.1
Comment 6 rlk 2014-08-09 23:41:58 UTC
Still present in 4.3.1.1.
Comment 7 rlk 2014-10-04 20:52:27 UTC
Still present in 4.3.2.2.

A bit more information: if I do Optimal Row Height, the rows all show up with a height of 0.18" (should be 0.10").  I can manually set the row height to 0.10", but if I rerun optimal row height, it goes back to 0.18".

Trying this with other font sizes, it appears that Optimal Row Height never sets a height less than 0.18".  I don't believe it's related to file/open per se; this looks like a change in behavior of optimal row height.

This looks very similar to bug 83568.
Comment 8 rlk 2014-10-05 03:47:14 UTC
I've searched the bug lists for other problems related to row height that start in the 4.2 release and added the See Alsos.
Comment 9 Cor Nouws 2014-11-01 11:29:22 UTC
*** Bug 80059 has been marked as a duplicate of this bug. ***
Comment 10 Cor Nouws 2014-11-01 11:32:27 UTC
Hi,

Set to 4.2.1.1 - the first version that I could reproduce the duplicate bug 80059 in.
Also to Hardware All - I'm on 32 bits.
In the description of 80059 there is a simple sheet + 'editing' instructions to reproduce.
Comment 11 tommy27 2014-11-21 22:02:03 UTC
still reproducible with LibO 4.3.3 and 4.4.0 beta1
since 4.2.x reached the END of LIFE I move this bug from mab4.2 to mab4.3 list.
Comment 12 rlk 2014-12-06 03:25:21 UTC
Here's a much simpler way to reproduce what appears to be this issue.

Start with a completely empty spreadsheet (File->New->Spreadsheet -- yes, that simple!)

Enter

=1&unichar(10)&2

into cell A1

Note how rows 1 and 2 get messed up, and how the row indices to the left of the spreadsheet are out of sync with the actual spreadsheet rows.
Comment 13 Matthew Francis 2015-01-11 15:10:55 UTC
The behaviour with respect to the originally reported bug (comment 0) changed as of the below commit. The issue reported in comment 12 is a separate issue, and has been raised as bug 88291.


commit 29b322ea0c40423a39efe2f6c2c85a7d2108c512
Author: Kohei Yoshida <kohei.yoshida@collabora.com>
Date:   Thu Jan 30 22:43:05 2014 -0500

    Keep the standard row height situation under control.
    
    With this change, applying cell attributes to default cells will
    no longer change the row heights inadvertently.
    
    Change-Id: I57c3546e1725c5e8b37696242e9642b1617f59c3
Comment 14 James L. Hammons 2015-01-12 16:46:38 UTC
This seems to have fixed the issue for me, at least as of version 4.3.2.2. Anyone else care to chime in? :-)
Comment 15 tommy27 2015-01-12 17:13:22 UTC
I still see that row 1627 looks larger than the others.
LibO 4.3.5.2 Win7x64
Comment 16 rlk 2015-01-16 14:19:30 UTC
Created attachment 112345 [details]
Screenshot showing incorrect row indices

I guess the spreadsheet I attached shows two bugs.  Note that the row indices below row 2 are incorrect and not aligned with the actual spreadsheet grid.
Comment 17 andréb 2015-02-26 19:00:00 UTC
(In reply to James L. Hammons from comment #14)
> This seems to have fixed the issue for me, at least as of version 4.3.2.2.
> Anyone else care to chime in? :-)

This bug still exists in 4.3.6.1
There are many other bug reports which would be resolved by reverting the minimal-row-height "feature".  This bug only partially describes the symptoms.
Any rows using only using text less than 10pt will have too large a height.
(My usual is 7 or 8pt.)
For those not in the US, for 8pt the default height was 3,6mm, and even smaller for smaller fonts.
It has now jumped to 4,5mm, an increase of 20%.  Which leaves 20% fewer lines displayed on a large spreadsheet.
Comment 18 tommy27 2015-05-29 21:15:30 UTC
retested attachment 97531 [details] 
issue persists in LibO 4.4.1.2 but is gone in LibO 5.1.0.0.alpha1+

Build ID: 6c1cabe677f5eb24b465dd6e316c8c66df64bb29
TinderBox: Win-x86@39, Branch:master, Time: 2015-05-29_06:48:08
Locale: en-US (it_IT)

Row 1627 has the same size as the others in LibO 5.1

so I set status to RESOLVED WORKSFORME

feel free to reopen if you don't agree.
Comment 19 Robinson Tryon (qubit) 2015-12-15 11:03:19 UTC
Migrating Whiteboard tags to Keywords: (bibisected)
[NinjaEdit]