1196126 - Long lines in custom non-editable textarea fields should wrap

Status: RESOLVED FIXED

(Bugzilla :: Creating/Changing Bugs, defect)

Description

[Peter Florijn]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:40.0) Gecko/20100101 Firefox/40.0
Build ID: 20150807085045

Steps to reproduce:

Custom fields already present in < 5.0 now behave different. Users complain about that the text is not show completely, only in edit mode.


Actual results:

Users complain about that the text is not show completely, only in edit mode.

Comment 1

[:glob ✱]

can you please provide two screenshots of a fields with text that isn't shown completely, both before and after clicking edit?

looking at the code if a field has a value it should always be visible even without clicking edit.

Comment 2

[Colin Joy]

Attachment: Custom Field Textarea View States

Going by the bug description, the problem is likely not visibility per se, but the content being cut off (differently). 

In 4.x, the non-expanded cf_textarea displays approx. 255 chars.
In 5.x, the non-expanded (edit) cf_textarea displays approx. 55 chars with lines cut being cut off in between (rendering lines 2 & 3 somewhat useless as they lack context). 

The 5.x version consumes about the same screen space as the 4.x version, but with decreased usability.

(attached screenshot only shows 5.x)

Comment 3

[Peter Florijn]

Comment on attachment 8650981 [details]
Custom Field Textarea View States

Thanks @colin for clarifying this bug. This is the behavior we experience

Comment 4

[Frédéric Buclin]

Attachment: screenshot with 5.1

I cannot reproduce the extra blank lines that Colin sees between text in comment 2. Probably unrelated to this issue.

I tested with 4.4 and 5.1, and both display the whole text correctly when I'm logged out. No text is truncated, as expected. For the record, the field contains two paragraphs.

When I'm logged in, 4.4 displays the editable textarea. In 5.0, we changed this behavior to display a readonly version of the field, and you have to click the (edit) link to see the editable textarea field. That's intentional. The only bug I can see is that the readonly field doesn't wrap long sentences, and so my two paragraphs are displayed on two lines only, one per paragraph, with a horizontal scrollbar to read the remaining text. This is really annoying. I guess that's what Peter is talking about. If yes, then I agree that the readonly field should wrap long lines to avoid the horizontal scrollbar. Only the vertical scrollbar should remain if there is a lot of text.

The screenshot shows what I see when I'm logged in and logged out.

Comment 5

[Frédéric Buclin]

I think that <pre> should be replaced by <textarea> so that long lines wrap correctly, and at least 3 or 4 lines should be displayed. Maybe all you need to do is to add a 'disabled' attribute to the existing textarea. If this doesn't work because it doesn't let you scroll, then it could be replaced by a <div> with CSS to limit its size. Something like the uneditable CC list.

Comment 6

[:glob ✱]

(In reply to Frédéric Buclin from comment #5)
> I think that <pre> should be replaced by <textarea> so that long lines wrap
> correctly, and at least 3 or 4 lines should be displayed.

(ab)using a textarea here would be a mistake - use css to get the overflowed text to wrap instead inside the <pre>.

Comment 7

[Colin Joy]

(In reply to Frédéric Buclin from comment #4)
> Created attachment 8650992 [details]
> screenshot with 5.1
> 
> I cannot reproduce the extra blank lines that Colin sees between text in
> comment 2. Probably unrelated to this issue.
> 

The extra blank lines are in fact paragraph spacing. 
The field contained 3 lengthy paragraphs.

I agree that the content should wrap. 

(In reply to Byron Jones from comment #6)
> (ab)using a textarea here would be a mistake

Can you elaborate why? My guess is stylistic formatting, but there may be other reasons.

A textarea would provide some free usability benefits over using a <pre>:

- Ability to easily copy the entire field content: a disabled form field supports CTRL-A / "select all".
- Browsers (apart from IE) will add resize handles to textareas, improving readability on fields with a large amount of text. 

I am not sure this behaviour can be emulated cleanly using a pre (without contenteditable).

On the other hand:

- A textarea cannot display stylistic formatting (strong/em ...), a <pre> can.

For any solution involving overflow, keep in mind that most users on OS X will not see a scrollbar on overflow elements (as demonstrated on my screenshot). So the last line in the element must be partially visible (indicates overflow). Horizontal overflow is best avoided alltogether

Comment 9

[Frédéric Buclin]

Attachment: patch, v1

Comment 10

[Frédéric Buclin]

The culprit checkin is https://github.com/bugzilla/bugzilla/commit/dfb467e63. The CSS rules have not been fixed accordingly. dkl, this review is for you as you wrote the original code. :)

Comment 11

[David Lawrence [:dkl]]

Comment on attachment 8689236 [details] [diff] [review]
patch, v1

Review of attachment 8689236 [details] [diff] [review]:
-----------------------------------------------------------------

Thanks for fixing this :) r=dkl

Comment 12

[David Lawrence [:dkl]]

Been a bit since I did the approval flag thing, so forgot :)

Comment 13

[Frédéric Buclin]

To ssh://[e-mail]/bugzilla/bugzilla.git
   88a2104..56d18c6  master -> master

To ssh://[e-mail]/bugzilla/bugzilla.git
   5fc8da0..5919408  5.0 -> 5.0