Confirmed the behavior for LO 3.5.7 up to LODev 3.6.5.

(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

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

(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

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)

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.

(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

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

*** Bug 99118 has been marked as a duplicate of this bug. ***

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).

*** Bug 99459 has been marked as a duplicate of this bug. ***

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.

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.

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.

@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

*** This bug has been marked as a duplicate of bug 118729 ***

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.

(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.

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?)

(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.

Related problem that definitely is a bug is: PDF export and print (preview too) look different to what's on screen when editing.
- Following steps in comment 4, export/print have a larger row height to accommodate the overflowing wrapped text;
- in some other cases, the overflowing text overlaps onto the next row in the export/print. See bug 112569 and its "see also"s.

Another issue: if a cell has such a "wrapped text overflow", the row height does update when applying e.g. a border to the cell. Surely we can't justify not updating the row height on resizing a column, but updating it when applying a border...

But all these issues need breaking into precise reports with simplest steps, if not already reported. The more I test this area, the more I see inconsistencies between canvas and export/print, and use of the overflow indicator, depending on steps and their order.