text comments are wrapped poorly, making them hard to read and confusing

[Scott Moser]

When viewing a bug with 'in-reply-to' like indentation (likely sent from an email client), or with a traceback, code or machine output, the comments are wrapped and hard to read. See the screen shot for an example taken from firefox-3.5 on karmic.

If the user shrinks the font the wrapping can actually look good. That would actually make sense except for the fact that inside the comment box there is large amounts of whitespace to the right (ie, there is no reason for this to wrap).

examples:

  https://bugs.launchpad.net/bzr/+bug/411296
  https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/720853

see also bug 30002 asking for actual markup so the user can control when/wrap things wrap

[Scott Moser (smoser)]

Here is a screenshot with text shrunk 2 times. The wrapping here is much more readable.

[Scott Moser (smoser)]

Note, the screenshots above were taken from bug 434693 comment 4.

[Michael Bienia (geser)]

That's because the max width of a text element is set to 45 em which is too less for commented lines

p, li, dt, dd, blockquote {
    max-width: 45em; /* Wrap the text before the eye gets lost. */
    }
(from style-3-0.css)

Setting it to 50 (with firebug for testing) lessen the effect you see.

[Gavin Panella (allenap)]

On FF 3.5 on Jaunty I can reduce the page width to 800px and the
wrapping does not happen. If I increase the font size then it
does.

What is the maximum viewport width at which the ugly wrapping still
happens?

Are you using the default font size? Can you make sure you're not
using something like No Squint to automatically adjust the zoom level?

Have you changed the default monospace font in the browser or on the
desktop? Are you running any other FF plugins that might be changing
font settings?

If you're running any Greasemonkey scripts, please can you try the
page with it disabled?

Can you force-reload the page to make sure you get the most up-to-date
style information for Launchpad? (I don't think this is a problem from
the screenshots, I just want to eliminate the possibility).

[Scott Moser (smoser)]

Well, I just created a brand new firefox profile (karmic, 3.5.3), so that should ('m not at all an expert at such things):
- default font size
- "No Squint"
- default font
- greasemonkey scripts
- force-reload.

As far as I know, I've not touched the desktop settings for "Monospace". And I just verified, it says "Monospace 10"

Attached is a screenshot from the "default" firefox.
Note, that no wrapping has been done due to the width of the window. I can widen it as much as possible and there is no change.

[Scott Moser (smoser)]

Was there anything else you needed from me? This bug is more than a bit annoying. I'm seeing it all over the place, and I don't believe my configuration is anything outside of "default" in this regard.

[Martin Pool (mbp)]

I have a branch, lp:~mbp/launchpad/bug-width , that sets the max-width for text to 80em. That seems to be a more reasonable tradeoff between

 a- not overly mangling terminal output or pre-wrapped email text
 b- not being overly wide when viewed on a large fullscreen window

example screenshot attached

[Martin Pool (mbp)]

before

[Martin Pool (mbp)]

after

[Martin Pool (mbp)]

https://code.launchpad.net/~mbp/launchpad/bug-width/+merge/80161

[Martin Pool (mbp)]

After discussion with Huw this is only likely to be fixed by adding markdown or other text rendering to lp.

[Martin Pool (mbp)]

> I think the majority of bugs in Launchpad do not include code/tracebacks in their descriptions, I wouldn't want to make it harder to read all of them for the sake of those that include code/tracebacks.

Here is a dump of the descriptions of ~200 recent public bugs. In fact, many of them do have code, tracebacks, or other structured/machine data that will look better displayed without too much wrapping.

[Martin Pool (mbp)]

https://bugs.launchpad.net/ubuntu/+source/bzr/+bug/720853 is an example where the traceback suffers poor readability because of being wrapped, and at first glance gratuituously so because (on my screen) there is so much white space to the right of it.

However, it is currently wrapping at ~80 cols, and perhaps there really is no width that will fit these things but not make plain text too long, and therefore we should just do markup and leave it up to the user.

I think this particular bug, too, is conflating a specific actual technical failure originally hit by Scott, with the general issue of text being too narrow.

[Martin Pool (mbp)]

So, maybe we should just close this bug: if we're going to wrap at any particular width, the current one of ~85 columns is as reasonable as anything else, and filling the whole browser window is likely to be too wide for a lot of text.

If Scott was originally seeing things wrap at even much less than that, on Karmic, that's a separate bug, and perhaps now obsolete.

Eventually per bug 30002 we will do proper markup and let the user tell us what ought to be wrapped and what not.

If you disagree you can say so.

[Grondr (grondr)]

Um. If you could please look at Bug #752197, you'll find that all the intervening discussion has wandered off into the weeds and completely missed the point of that bug, of which I was the OP some six months ago. That bug was very simple---don't have the default text box into which I am typing this comment right now be -wider- than the way you render the text I'm typing. That guarantees ugly, unreadable wrapping, -and- since I can't preview how it'll appear, I'm forced to guess (or carefully count characters) every single time I type in a comment or it'll look bad. (For this particular comment, I typed it directly into the box with no hard returns except for paragraph breaks, so maybe it'll be autowrapped correctly, but in general I yank text in from Emacs and then it's got hard returns that then cause the wrapping to malfunction due to the mismatch. See also my comment in that bug about how itemized lists don't get wrapped at all and hence overflow when rendered.)

And fixing -that- seems much, much more straightforward than complicated markup and all that. It just means making the typein box and the renderer agree with each other. But since that bug got merged with this one, and this one wandered off into the weeds, it's looking like that really easy fix is just never going to happen. I've had several other bugs take the same route through Launchpad, btw---report a relatively simple thing, have it discussed to death across several releases, and eventually buried by "we'll write a new piece of software because we won't make the easy fix" [which in several cases would have been to -revert- some misguided code]. And then it dies, because no one ever gets around to writing the new thing (if the new thing even solves the original problem, which in some cases it can't). I'd file a bug report on the process itself, but...

*sigh* I don't file enough bug reports that this is going to ruin my day, but I do hope that it'll get fixed someday. Thanks.

[Martin Pool (mbp)]

Thanks for flagging that, Grondr. That is a valid, but separate bug.
It may be a dupe of a different bug about inconsistency between entry
textareas and text display.

I sympathize with your frustration about things being duped and then
lost. It is at least as much an outcome of a human process as it is
any particular technical bug.