Bug Hunting Session
Bug 118729 - Word wrap isn't working after a reducing the column size
Summary: Word wrap isn't working after a reducing the column size
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.0.0.5 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
: 122822 (view as bug list)
Depends on:
Blocks:
 
Reported: 2018-07-12 14:46 UTC by Telesto
Modified: 2019-08-08 16:15 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments
Bibisect log (2.91 KB, text/plain)
2018-07-13 11:48 UTC, Telesto
Details
Screenshot LibO 4.4.7.2 (41.49 KB, image/png)
2018-07-13 13:39 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-07-12 14:46:12 UTC
Description:
Word warp isn't working after a column downsize

Steps to Reproduce:
1. Open attachment 143392 [details] (bug 118630)
2. Downsize column A -> Arrow for hidden text appears. However wrapped text is enabled
3. Clicking somewhere in the document doesn't change anything (it does in 4.4.7.2)



Actual Results:
Word warp isn't working properly

Expected Results:
Should be working like LibO 4.4.7.2 



Reproducible: Always


User Profile Reset: No



Additional Info:
Found in
Version: 6.2.0.0.alpha0+
Build ID: 8e9d43546c8e46ea635472ddf07f5c183dc13360
CPU threads: 4; OS: Windows 6.3; UI render: GL; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-07-12_01:16:00
Locale: nl-NL (nl_NL); Calc: CL

and in
Version: 5.1.0.0.alpha1+
Build ID: 87ac0b1e75a880a68ecb748bd4b34ae5a3d2ae98
Locale: nl-NL (nl_NL)

no repro with
Version: 4.5.0.0.alpha0+
Build ID: 57d6b92b69a31260dea0d84fcd1fc5866ada7adb
Locale: nl_NL
Comment 1 Telesto 2018-07-13 11:48:57 UTC
Created attachment 143533 [details]
Bibisect log

Bisected to
author	Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>	2015-05-07 14:18:37 +0900
committer	Jan Holesovsky <kendy@collabora.com>	2015-05-07 09:57:50 +0200
commit	dca01def7885ad69cf66edd75cf8207a5adb64f9 (patch)
tree	f3b43717ab058b677c68614bcb2953beb7c7d1a0
parent	7a11ec1992bf877f42edce8d1d930c5b00bd3d48 (diff)
refactor ListBox/ComboBox to use RenderContext
Comment 2 OfficeUser 2018-07-13 13:19:51 UTC
I don't get the point. If the width AND height is too small for the context an overflow arrow is indicated. If What behavior do you expect? Could you provide screenshots please?
Comment 3 Telesto 2018-07-13 13:39:26 UTC
Created attachment 143535 [details]
Screenshot LibO 4.4.7.2
Comment 4 OfficeUser 2018-07-13 14:11:32 UTC
@Telesto: Thanks for the screenshot. Do you mean that LibO 4.4.7.2 automatically increases the hight after reducing the width? If yes, I am not sure if this behavior is the "better" one.
You need just to double-click the row divider line on the left side to restore a best fit row height.


The behavior of recent LibO build (I have tested 6.0.3.2) - NOT to adjust the row height automatically after changing the column width - seems reasonable to me. In addition I found that MS Excel 2013.
Comment 5 OfficeUser 2018-07-13 14:12:11 UTC
... behaves identical.
Comment 6 OfficeUser 2018-07-13 14:15:26 UTC
Set keyword needsUXEval. I vote for keeping the behavior as it is at the moment (LibreOffice 6).
Comment 7 Telesto 2018-07-13 15:05:47 UTC
(In reply to OfficeUser from comment #4)
> @Telesto: Thanks for the screenshot. Do you mean that LibO 4.4.7.2
> automatically increases the hight after reducing the width? If yes, I am not
> sure if this behavior is the "better" one.
> You need just to double-click the row divider line on the left side to
> restore a best fit row height.


Do you mean that LibO 4.4.7.2 automatically increases the hight after reducing the width
-> Yes

> The behavior of recent LibO build (I have tested 6.0.3.2) - NOT to adjust
> the row height automatically after changing the column width - seems
> reasonable to me. In addition I found that MS Excel 2013.

Yes, indeed. However the height of the cell gets adjusted after 'entering' (A1) in Excel, but not in Calc. Calc changes the height after some edit in A1
Comment 8 V Stuart Foote 2018-07-13 15:51:41 UTC
I don't see an issue here--cell/row height direct formatting should be detached from "Wrap text automatically" Cell formatting of the style.

Apply the "Optimal Row Height" direct formatting from Format -> Row -> Optimal Height or the context menu.  Likewise for direct formatting of the Column width from Format or context menu. 

Believe this is working correctly.
Comment 9 OfficeUser 2018-07-13 16:24:21 UTC
I agree with Stuart.


Further reasons are:

1. If the user clicks into a cell to "enter" it he normally does NOT intent a height adjust.

2. An easy hight adjust can be triggered by double-clicking the row divider line on the left side (at the row buttons).
Comment 10 Telesto 2018-07-13 18:42:54 UTC
To start with: I reported this bug because of the change in behaviour, not because I care about the outcome. So, if this is what we want, it's fine.

However, the current behaviour is still inconsistent in any case (or lacking a proper explanation). 

@ Stuart
Cell/row height direct formatting should be detached from "Wrap text automatically" Cell formatting of the style.

-> this isn't truly the case at the moment. cell/row height adjustment happen quite often with "Wrap text automatically" enabled

Situation 1
1. Format Cell -> Alignment tab -> Wrap text automatically
2. Start typing to get a few lines/rows of text -> Cell Height will be adjusted automatically

Situation 2
1. Reduce the column width
2. Enter the cell with multiline content and make an adjustment (or apply ing a autocorrection) -> cell height will be adjusted

Situation 3
1. Reduce the column width
2. Double-clicking the row divider line on the left side (at the row buttons). -> cell height will be adjusted

And it's broken in this case
1. Instead of reducing, increase the column width (from situation 1) -> the row height won't adjust (which is the opposite of my initial report)
2. It's only correct with step 2 of situation 2 and 3. And this isn't obvious. 

---

Possible solutions
1. Detach cell height from "Wrap text automatically" in all cases
2. Go back to the initial situation of LibO 4.4.7.2
Comment 11 Telesto 2018-07-13 18:58:35 UTC
Some other bug reports related to wrapping & column height. 
bug 32950 
bug 57519 
bug 65200
Comment 12 OfficeUser 2018-07-13 21:05:11 UTC
Duplucate of Bug 57519?
Comment 13 Buovjaga 2018-07-14 14:44:42 UTC
(In reply to V Stuart Foote from comment #8)
> I don't see an issue here--cell/row height direct formatting should be
> detached from "Wrap text automatically" Cell formatting of the style.
> 
> Apply the "Optimal Row Height" direct formatting from Format -> Row ->
> Optimal Height or the context menu.  Likewise for direct formatting of the
> Column width from Format or context menu. 

I don't get how they could be detached as automatic increasing of height is the main point of wrapping. Or do you propose to remove the height increasing functionality entirely, so the text would wrap horizontally when typing, but go out of sight vertically while displaying the red triangle?

This was not discussed in a design team meeting, so I don't understand the dance with the keyword and CC. If this is decided to be notabug and the behaviour even further changed, it is such a significant change that it has to be dealt with in a meeting. There is a large body of users that considers this to be a bug since years (in AskLibO, BZ...).

If this is decided to be notabug, then all the other reports need to be analysed and closed if needed (at a minimum bug 57519).
Comment 14 V Stuart Foote 2018-07-14 15:48:02 UTC
(In reply to Buovjaga from comment #13)
> (In reply to V Stuart Foote from comment #8)
> > I don't see an issue here--cell/row height direct formatting should be
> > detached from "Wrap text automatically" Cell formatting of the style.
> > 
> > Apply the "Optimal Row Height" direct formatting from Format -> Row ->
> > Optimal Height or the context menu.  Likewise for direct formatting of the
> > Column width from Format or context menu. 
> 
> I don't get how they could be detached as automatic increasing of height is
> the main point of wrapping. Or do you propose to remove the height
> increasing functionality entirely, so the text would wrap horizontally when
> typing, but go out of sight vertically while displaying the red triangle?
> 

Testing sample document with current master/6.2.0, the documents sheet presents a "default" Cell Style without "Wrap text automatically" enabled.

Meaning the example cell *is* under Direct Formatting to wrap its text.

Modify the default style to include the wrap text automatically, and apply it (the Update Style on the content panel).  Alignment/wrap within the cells is picked up from the style as opposed to the direct formatting.

And, with the change to Cell Style, all other cells being entered will wrap within their Column width as set, shifting height--the desired behavior.

Beyond the row height response when the Sytle to wrap text is enabled, IIUC controlling column width and row height is not done by any cell style and so any change to set "Optimal Height / Optimal Width" are Direct Formatting of the selected cells or columns/rows. 

So again, I don't see an issue here (other than our on going challenge of educating users (and QA members) about styles vs direct formatting)--but I could be wrong.

I've no concern with taking this back through UX-Advise, but the behavior seems correct IMHO.
Comment 15 Buovjaga 2018-07-14 16:14:29 UTC
(In reply to V Stuart Foote from comment #14)
> So again, I don't see an issue here (other than our on going challenge of
> educating users (and QA members) about styles vs direct formatting)--but I
> could be wrong.

I tried wrapping through Default style, but it behaves just like direct formatting. I decrease column width and the text is cropped in the vertical axis. So I'm not sure how this is about styles vs. direct formatting education.

This is rather about user expectations concerning the automatic applying of direct formatting: why is the automated height increase tied to inputting content, but not to changing of column width?
Comment 16 Heiko Tietze 2018-07-23 11:35:52 UTC
I agree with Stuart and Norbert on WFM. Try with blind text from Writer (or any other lengthy passage of text) in older version to see how odd the increase of row height is. 

(In reply to Buovjaga from comment #15)
> I tried wrapping through Default style...

Sounds like a different topic; Default is defined with wrap off and I think typical text is short like two words and must not change the vertical alignment over multiple cells, which happens after wrapping. In any way we will make some people unhappy.
Comment 17 Heiko Tietze 2018-07-23 11:38:52 UTC
Correction: cell height is only kept when defined by the user. Meaning when you paste text into a new document without changing the row height and wrap it grows over the total size. If the height has been defined before this value is kept. It's the same in 5.2.7 and 6.1 (and works for me).
Comment 18 OfficeUser 2018-07-23 12:39:12 UTC
*** Bug 57519 has been marked as a duplicate of this bug. ***
Comment 19 Buovjaga 2018-07-23 13:17:06 UTC
I tested with Excel 2013 and there the behaviour is:
1) Change the width of a wrapped cell, text gets cropped vertically (like with LibO)
2) Double-click to the cell from step 1) and click away: the height adapts to display the full text (LibO does not do this)

I tried to bisect when the behaviour requested by Telesto to be restored was originally introduced. I used 42max, but unfortunately I had to do lots of skipping. The final repo commit suspects were these and I checked them all, but none seemed relevant:

48e32d82ffcda002119406d63883ea9ba6d8d247
db5c1d100da992d2e0d5a136bc088ca950df21f0
879f76934acd213633a14c0c3159aa37d257ec3e
ae365233a4aa760e2b5d928613499cb99bbc32a6
2a78305e74a6ef4264be5403d584a841a4cba575
7425db1c97608fc3511860cffec844fe94e3881c
03cf2c53d4f2e8952398c8480e3ecd0c8e0ec556
9959d84880039df48d778723be0fb4a9e804b60a
50d75b98bfc24457d454ca4b2660808c43d4149f
d74bfb2206795e5f4ddd8f37d004f452b1b0176c
38dad5aca61b3ae0ec1df3122ee00bbac7ee442e
677c6defa69745545cd85a2b25b28494959233fe
06271499c829a52c702c2c6dc8f99c2ec9c46fd3
7df4615583a9c8219e64918809b95a76a294359a
86cb6230299035756352ceb751a18a495356dca2

I also verified Telesto's bisect result from comment 1.

(In reply to Heiko Tietze from comment #16)
> I agree with Stuart and Norbert on WFM. Try with blind text from Writer (or
> any other lengthy passage of text) in older version to see how odd the
> increase of row height is.

I'm not sure I follow you - what older version? This has never worked in the ideal way of the user request in bug 57519.

> 
> (In reply to Buovjaga from comment #15)
> > I tried wrapping through Default style...
> 
> Sounds like a different topic; Default is defined with wrap off and I think
> typical text is short like two words and must not change the vertical
> alignment over multiple cells, which happens after wrapping. In any way we
> will make some people unhappy.

It's not a different topic. I tried it only because Stuart said this was somehow about direct formatting vs. styles (it was not). It sounds like you misunderstood somehow: nobody is requesting wrapping to be turned on by default.

(In reply to Heiko Tietze from comment #17)
> Correction: cell height is only kept when defined by the user. Meaning when
> you paste text into a new document without changing the row height and wrap
> it grows over the total size. If the height has been defined before this
> value is kept. It's the same in 5.2.7 and 6.1 (and works for me).

I don't know what this has to do with the topic.
Comment 20 Telesto 2019-08-08 16:15:34 UTC
*** Bug 122822 has been marked as a duplicate of this bug. ***