Bug Hunting Session
Bug 57519 - Cell wrap does not function automatically once column width is reduced
Summary: Cell wrap does not function automatically once column width is reduced
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
Inherited From OOo
Hardware: x86 (IA32) All
: high minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 99118 99459 (view as bug list)
Depends on:
Blocks: Calc-Cells
  Show dependency treegraph
 
Reported: 2012-11-25 14:37 UTC by Mohith Manoj
Modified: 2018-07-24 16:25 UTC (History)
7 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 Mohith Manoj 2012-11-25 14:37:40 UTC
When work wrap is enabled for a cell (or cells), the row height is automatically increased or decreased to fit the content. However, if the column width is modified (increased / decreased), the row height of filled cells does not update automatically.

Becomes a problem when the column width is reduced and the contents gets hidden.

Issue reported in a wiki post @ ask.libreoffice.org
http://ask.libreoffice.org/question/8225/cannot-wrap-text-in-cells-in-calc/
Comment 1 Horst 2012-11-26 19:42:54 UTC
Confirmed the behavior for LO 3.5.7 up to LODev 3.6.5.
Comment 2 Jorendc 2013-02-03 22:04:23 UTC Comment hidden (obsolete)
Comment 3 Jorendc 2013-02-03 22:06:59 UTC
(In reply to comment #2)
> Is it still reproducible using LibreOffice 4.0?

Sorry for my change, but therefore I'll set Bug Status to NEEDINFO. I know there are made some changes in 4.0 quite related to this issue. Therefore I ask this to retest. Thanks for your time.

Kind regards,
Joren
Comment 4 Bernhard Dippold 2013-03-13 22:09:04 UTC
reproduced on Version 4.0.0.3 (Build ID: 7545bee9c2a0782548772a21bc84a9dcc583b89)
on WinXP.

Recalculation of row height is not done until a new line wrap (forced by a word passing the right border of the cell) is done.

Steps to reproduce:

1. in Calc select a cell and format it with automatic word wrap (Format - Cells - Tab:Alignment - wrap text automatically: Check).

2. Add text that floats over the right border of the cell.

3. Result: Text is wrapped to fit cell width, row height is adapted to fit the content.

4. Reduce the width of the cell (just move the right border of the column header a bit to the left) until word wrap forces a new line of text.

5a. Expected result: Similar to 3.

5b. Present result: Text floats to a new line in the cell, but row height stays the same. The new line is not visible, but a red triangle on the right border of the cell indicates that there is more text in the cell.

6. Add more text to the cell without forcing a new word wrap.

7a. Expected result: Similar to 3.

7b. Present result: Similar to 5b.

8. Add more text, so a new line is necessary.

9. Result: Similar to 3.

HTH - if this info is sufficient, please change status.

Thanks Bernhard
Comment 5 Jorendc 2013-03-14 10:59:17 UTC
(In reply to comment #4)
> reproduced on Version 4.0.0.3 (Build ID:
> 7545bee9c2a0782548772a21bc84a9dcc583b89)
> on WinXP.

Well done Bernhard! Thanks for your clear steps. I didn't test them yet, but because you can reproduce it I mark this as NEW for now. I'm currently building, so I'll test later.

Kind regards,
Joren
Comment 6 Bernhard Dippold 2013-03-14 23:37:04 UTC
Just to add: Still the same behavior in version 4.0.1.2 (Build ID: 84102822e3d61eb989ddd325abf1ac077904985) on Win XP.

And we could include the lack of reducing the height when you broaden the cell in order to reduce the number of text lines: 
In this case the row stays too high and the text is positioned according to the standard vertical alignment (in my case: at the bottom of the cell).

(if you want me to, I'll probably can provide a step-by-step description for this case too)
Comment 7 bugquestcontri 2014-08-11 01:14:43 UTC
Being triggered by http://ask.libreoffice.org/en/question/38096/wrap-is-inconsistent/?comment=38100#comment-38100

I confirm the bug still exists in Version: 4.2.6.2
Build ID: 185f2ce4dcc34af9bd97dec29e6d42c39557298f
running on XP Pro / SP3

It is actually a pretty annoying bug when task lists need to be created. It slows down productivity a lot.
Comment 8 ign_christian 2014-08-11 02:01:41 UTC
(In reply to comment #4)
> 5b. Present result: Text floats to a new line in the cell, but row height
> stays the same. The new line is not visible, but a red triangle on the right
> border of the cell indicates that there is more text in the cell.

Reproduced in LO 4.3.1.1, 3.3.0.4 - Ubuntu 12.04 x86

Also in AOO 4.1.0, looks inherited from OOO
Comment 9 QA Administrators 2015-09-04 02:48:13 UTC Comment hidden (obsolete)
Comment 10 Bernhard Dippold 2015-09-18 20:09:12 UTC
Tested on 
Version: 5.0.0.5
Build-ID: 1b1a90865e348b492231e1c451437d7a15bb262b
Windows Vista Business SP 2

Reproducing in comparison to comment #4, there is a different behavior in Step 7:

> 1. in Calc select a cell and format it with automatic word wrap (Format - 
> Cells - Tab:Alignment - wrap text automatically: Check).
done

> 2. Add text that floats over the right border of the cell.
done

> 3. Result: Text is wrapped to fit cell width, row height is adapted to fit
> the content.
same

> 4. Reduce the width of the cell (just move the right border of the column
> header a bit to the left) until word wrap forces a new line of text.
done

> 5a. Expected result: Similar to 3.
same

>5b. Present result: Text floats to a new line in the cell, but row height
> stays the same. The new line is not visible, but a red triangle on the right
> border of the cell indicates that there is more text in the cell.
same

> 6. Add more text to the cell without forcing a new word wrap.
done

> 7a. Expected result: Similar to 3.
same

> 7b. Present result: Similar to 5b.
DIFFERENT: When the cell content is updated, line wrap is recalculated an height adjusted -> similar to 3.

> 8. Add more text, so a new line is necessary.
same

> 9. Result: Similar to 3.
same

So the bug is still present, but only when the column width is modified.

If you enter any text in this cell or in another cell with automatic word wrap that needs recalculation (text longer than cell width or removal of a character), row height is recalculated.

Best regards
Bernhard
Comment 11 Buovjaga 2016-04-19 10:48:49 UTC
*** Bug 99118 has been marked as a duplicate of this bug. ***
Comment 12 Koen 2016-04-24 08:53:32 UTC
Ubuntu 14.04
Version: 5.1.1.2
Build ID: 1:5.1.1~rc2-0ubuntu1~trusty0

Can confirm the following (from Bernhard Dippold from comment #10):

> Reproducing in comparison to comment #4, there is a different behavior in
> Step 7:
> 
> > 1. in Calc select a cell and format it with automatic word wrap (Format - 
> > Cells - Tab:Alignment - wrap text automatically: Check).
> done
> 
> > 2. Add text that floats over the right border of the cell.
> done
> 
> > 3. Result: Text is wrapped to fit cell width, row height is adapted to fit
> > the content.
> same
> 
> > 4. Reduce the width of the cell (just move the right border of the column
> > header a bit to the left) until word wrap forces a new line of text.
> done
> 
> > 5a. Expected result: Similar to 3.
> same
> 
> >5b. Present result: Text floats to a new line in the cell, but row height
> > stays the same. The new line is not visible, but a red triangle on the right
> > border of the cell indicates that there is more text in the cell.
> same
> 
> > 6. Add more text to the cell without forcing a new word wrap.
> done
> 
> > 7a. Expected result: Similar to 3.
> same
> 
> > 7b. Present result: Similar to 5b.
> DIFFERENT: When the cell content is updated, line wrap is recalculated an
> height adjusted -> similar to 3.
> 
> > 8. Add more text, so a new line is necessary.
> same
> 
> > 9. Result: Similar to 3.
> same
> 
> So the bug is still present, but only when the column width is modified.
> 
> If you enter any text in this cell or in another cell with automatic word
> wrap that needs recalculation (text longer than cell width or removal of a
> character), row height is recalculated.
> 
> Best regards
> Bernhard

As well as (from Bernhard Dippold from comment #6):
> And we could include the lack of reducing the height when you broaden the
> cell in order to reduce the number of text lines: 
> In this case the row stays too high and the text is positioned according to
> the standard vertical alignment (in my case: at the bottom of the cell).
Comment 13 Buovjaga 2016-05-02 12:50:11 UTC
*** Bug 99459 has been marked as a duplicate of this bug. ***
Comment 14 Kumar Thangavel 2017-04-05 07:38:25 UTC
I confirm this bug and tested on

Version: 5.4.0.0.alpha0+
Build ID: 5d0e485e827057eee9fb2c997685690b710e7f34
CPU threads: 8; OS: Linux 4.7; UI render: default; VCL: gtk3; 
Locale: en-IN (en_IN.utf8); Calc: group

Also, I would like to work on this bug.

Thanks.
Comment 15 Xisco Faulí 2017-10-23 09:09:59 UTC
Dear Kumar Thangavel,
This bug has been in ASSIGNED status for more than 3 months without any activity. Resetting it to NEW.
Please assigned it back to yourself if you're still working on this.
Comment 16 Dan Loomis 2018-01-15 06:31:46 UTC
Happens when cell width is adjusted or when text data is entered into a cell and Calc automatically wraps the text.   When new lines are added the row height should be adjusted.   

Version: 5.4.4.2
Build ID: 5.4.4.2-1.fc27

Workaround:  Format --> Cells --> Alignment tab: Click the wrap text automatically box off and back on.
Comment 17 Telesto 2018-07-14 07:58:43 UTC
@Buovjaga
I'm getting a little confused here. The cell height is adjusted when reducing the column width in 4.3.7.2 and 4.4.7.2 (except for a trigger is needed to adjust the  column height).

Clicking a different cell - which triggers the resize - is broken since LibO 5.0 (see bug 118729). Looks like the same issue as reported by bug 99118 and bug 99459
Comment 18 OfficeUser 2018-07-23 12:39:12 UTC

*** This bug has been marked as a duplicate of bug 118729 ***
Comment 19 Koen 2018-07-23 21:14:49 UTC
Reopening again. While indeed the issue seems to be similar/identical, the other issue has been closed and the issue not fixed. Looking at the timeline, bug 118729 is rather a duplicate of this one (not vice versa).

This one should be kept open until fixed.
Comment 20 Buovjaga 2018-07-24 08:09:14 UTC
(In reply to noreply from comment #19)
> Reopening again. While indeed the issue seems to be similar/identical, the
> other issue has been closed and the issue not fixed. Looking at the
> timeline, bug 118729 is rather a duplicate of this one (not vice versa).
> 
> This one should be kept open until fixed.

To make it clear, the design team rejected this change, so this will never happen. Closing as such.
Comment 21 Koen 2018-07-24 15:59:53 UTC
Really? That's an interesting decision. Is it not considered a bug per se, then? (Do you know where I can read about the motivation?)
Comment 22 Buovjaga 2018-07-24 16:25:50 UTC
(In reply to noreply from comment #21)
> Really? That's an interesting decision. Is it not considered a bug per se,
> then? (Do you know where I can read about the motivation?)

Everything I know about it can be read in bug 118729.

Personally, I would have liked to get the automatic height adaptation per width change, but if the design folks believe it would cause annoyance for others, I will not fight it.

That said, we might still become like Excel, where if you double-click inside the wrapped & width-reduced cell, the height increases.