436189 - Word wrap of comments broken by new CSS width constraint under certain fonts

Status: RESOLVED FIXED

(Bugzilla :: User Interface, defect)

Description

[Bob Kline]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5) Gecko/2008050509 Firefox/3.0b5
Build Identifier: 3.0.4

It appears that in February [1] a new CSS rule was introduced to improve the display of Japanese text without whitespace.  The rule looks like this:

.bz_comment_text {
    width: 50em;
}

So now there are two mechanisms for forcing word wrap in comment display: one using the introduction of line breaks based on character counts and the position of whitespace, and the other enforced by the new CSS width constraint.  Unfortunately these two mechanisms are not always compatible, and in Firefox 3 (I'm running Beta 5 on Linux) the result is broken word wrap.  To illustrate, here's a paragraph from our Bugzilla database pasted in without any line breaks:

I figured out that although comment #48 identified the attributes as "etype" and "elevel" the server is actually sending back attributes "cdr:etype" and "cdr:elevel"; however, I'm no longer getting the cdr:eref attributes, so we're still broken (on Mahler).  I'll work with Alan tomorrow to get this fixed.

Here's that same paragraph as it's currently displayed in this browser (line breaks added by me):

I figured out that although comment #48 identified the attributes as "etype"
and "elevel" the server is actually sending back attributes "cdr:etype" and
"cdr:elevel"; however, I'm no longer getting the cdr:eref attributes, so
we're
still broken (on Mahler).  I'll work with Alan tomorrow to get this fixed.

Apologies if this is a duplicate.  I did a search on "word wrap comment width" and a scan of the summaries for the 200 most relevant hits in the search result set didn't turn up any bugs which looked like this one, but I might have glazed over and missed it.

[1] Revision 5474 committed 2008-02-08 23:18:59 by mkanat%bugzilla.org for Bug 388723.

Reproducible: Always

Steps to Reproduce:
1. Open Firefox 3
2. Bring up any Bugzilla issue with substantial comments
3. Look for broken word wrap
Actual Results:  
Described above.

Expected Results:  
Word wrap generated by one mechanism or the other, but not both.

Comment 1

[Frédéric Buclin]

This bug looks similar to bug 425636, which was marked as INVALID.

Comment 2

[Bob Kline]

Similar, yes, but not the same.  I'm not using any custom fonts (Shaver's use of custom fonts was the basis of marking that bug INVALID).

Comment 3

[A. Shimono [:himorin]]

The line, which is wrapped in your browser, is wrapped or not in html?
# it might not be wrapped... of cource.

If you can, could you list applied CSS style rules to the element (for comment area)? Like using DOM Inspector w/ FF3 RC.
Without any custom skin definitions, i think you will get three rules. (related on .bz_comment_text)

Comment 4

[Bob Kline]

(In reply to comment #3)
> The line, which is wrapped in your browser, is wrapped or not in html?

Not (there's a newline after "we're" in the HTML source, but not between "so" and "we're").  The break is caused by the CSS width rule, whose decisions about were to break are not always consistent with the position of the inserted newlines.

> If you can, could you list applied CSS style rules to the element (for 
> comment area)? Like using DOM Inspector w/ FF3 RC.  Without any custom 
> skin definitions, i think you will get three rules. (related on 
> .bz_comment_text)

.bz_comment_text
{
    font-family: monospace;
    white-space: pre-wrap;
}

.bz_comment_text
{
    width: 50em;
}

Comment 6

[Max Kanat-Alexander]

I'm looking at this page in FF3 and it wraps just fine.

We cannot have word wrap generated by only one method, I believe I explained why in the bug where I introduced the CSS wrapping--it is impossible to tell a browser to wrap at exactly 80 characters, and also there were some other problems I encountered, like the fact that many browsers that we support do not support "pre-wrap".

So you could possibly argue, if you can prove that there is some environment somewhere where the wrapping is wrong by default with normal settings, that we should increase the width (please reopen the bug if you have some visual data that can show this). But we can't currently have only one wrapping method.

Comment 7

[Alexey Gaidukov]

In my environment in case with default settings there are no any visual problems. But in case of COMMENT_COLS=120 there is a problem. COMMENT_COLS=120 just doesn't work. Comments look like with COMMENT_COLS=80.

Comment 8

[Alexey Gaidukov]

Attachment: COMMENT_COLS=120, default CSS

Comment 9

[Alexey Gaidukov]

Attachment: COMMENT_COLS=120, without "width: 50em; "

Comment 10

[Max Kanat-Alexander]

Yes, perhaps we should add a comment above COMMENT_COLS that you also have to fix the CSS. Perhaps file another bug for that?

Comment 11

[Bob Kline]

Attachment: Screen image showing what new CSS does to paragraph word wrapping.

(In reply to comment #6)
> I'm looking at this page in FF3 and it wraps just fine.

Still broken in my environment (Firefox 3.0.5 running under Ubuntu 8.04, with default fonts and no customization of Bugzilla CSS for wrapping).

> So you could possibly argue, if you can prove that there is some environment
> somewhere where the wrapping is wrong by default with normal settings, that we
> should increase the width (please reopen the bug if you have some visual data
> that can show this).

I assume that by "visual data that can show this" you mean show you a screenshot.  I have attached a PNG image of an example of the problem.

Comment 12

[Bob Kline]

Re-opening the issue as requested.

Comment 13

[Max Kanat-Alexander]

Hmm. What's confusing to me is why your browser thinks that's 50em. Are you sure you don't have any custom CSS? FWIW, I'm looking at things on Linux myself (Fedora), and I don't have the same problem.

Comment 14

[Bob Kline]

Attachment: CSS loaded for the page from previous attachment

(In reply to comment #13)
> Hmm. What's confusing to me is why your browser thinks that's 50em. Are you
> sure you don't have any custom CSS?

Here's the CSS that's loaded for that page.  The browser doesn't have any custom CSS configured (not even sure I'd know how to do that).

Comment 15

[Max Kanat-Alexander]

(In reply to comment #14)
> Created an attachment (id=354646) [details]
> CSS loaded for the page from previous attachment

  That seems to be an empty attachment.

> The browser doesn't have any
> custom CSS configured (not even sure I'd know how to do that).

  It wouldn't be in the browser, it'd be something your Bugzilla administrator did with Bugzilla.

Comment 16

[Bob Kline]

Attachment: Same attachment with renamed file

Here's another attempt at posting the previous attachment; Firefox put some funky characters in the filename when I did a "Save As" for the CSS it collected for the repro case, and Bugzilla and/or Firefox got confused about how to find the file when I posted it as an attachment.

Comment 17

[Bob Kline]

Attachment: Third attempt at posting CSS

Well, the file name wasn't the problem.  Apparently, when you use the "File / Save As" command in Firefox for the page on which the developer toolbar has collected the CSS for a page loaded into the browser, it saves an empty HTML page.  Another bug, another software package.  I'm hoping this third attempt (using copy/paste) will succeed.

Comment 19

[David Hull]

If increasing COMMENT_COLS is causing the wrapping problem, perhaps it would be better to apply the width CSS constraint in a style attribute to the bz_comment_text pre tag, instead of in a separate CSS file, and use template toolkit to calculate the proper width from COMMENT_COLS instead of using a fixed value.  That way, if COMMENT_COLS is increased the pre width would automatically be increased as well.

Comment 20

[u81239]

From bug 485165, which was filed as duplicate (lots of duplicates here, it seems!):

I encountered this issue as I have increased my page zoom by 1 in Firefox 3 using CTRL-+, so that it is better readable on my 120dpi screen. COMMENT_COLS is on its default value, to my knowledge, and I use the default monospace font.

What happens is that for example the following line as I entered it:

> 1. IE7 / quirks mode does not propagate events from the iframe if it contains a PDF document.

Gets broken up as:

> 1. IE7 / quirks mode does not propagate events from the iframe if it
> contains a
> PDF document.

This happens because a comment field has a "white-space: pre-wrap" style. I
would suggest that as a fix, this be changed to "white-space: pre", or that the containing element be made wider, to fit to the width of the page.

~Laurens

Comment 21

[u81239]

Now that I think of it though, I did set a custom font size (again, because I’m working on a 120dpi screen).

Comment 22

[Max Kanat-Alexander]

Zooming doesn't matter, because we set our width in "em". The browser should be increasing the width proportionately to the zoom.

Comment 23

[u81239]

And yet it does. My default font size settings in Firefox are 17 pixels for proportional fonts, and 14 pixels for monospace fonts. If I set it now on the computer I’m on now, and press CTRL-+, the same thing happens.

By the way, if you set the width in em, probably you should take the em-width of the monospace font, not the em-width of the default proportional font.

Comment 24

[David Williams]

Attachment: screen capture showing poor flow

I also see things "messed up" on Firefox. I've lived with this for "years", and just discovered today the comment width correct resizes on Opera. I'm not actually sure if it is Firefox, per se, or less than ideal CSS ... but, something is amiss. I suspect the CSS style sheet, since even in Firefox the "quoted" lines are actually flowed and resized correctly. But unquoted lines end up getting wrapped a little early, leaving one or two words on next line, before hitting the actual EOL. Nasty to read. (Note, if I Veiw,Zoom the font smaller, it will display ok ... but, my prefered font size seems just large enough to through it all off. I hope the screen shot helps illustrate the problem. 

I here I was blaming those poor webmasters at eclipse.org :) 
https://bugs.eclipse.org/bugs/show_bug.cgi?id=291000

Comment 25

[David Williams]

FWIW, in doing some tests, using a copy of the files on my files system, changing width to 51 instead of 50 for 'comment text' seemed to fix the issue. That is, there would be no funny wrap of one word, no matter what zoom level I picked. 

.bz_comment_text {
     width: 51em;
}

Comment 26

[David Williams]

Well, even better, I see that changing to 'consolas' as default monospace font makes my problem go away. So ... I think there's just some computation somewhere for some fonts that are "off by one" in computing line width, somehow.

Comment 27

[David Williams]

What method was used to come up with the width of 50em? 

I can imagine one rationale: A typical mono spaced font is 12 pixels: 

12pixels x 50em = 600 pixels for the standard case? And 600 pixels being
thought a good typical pixal values for most browsers, most resolutions,
and seemed to work and look good for the test cases.


When I first started to think about this, I thought ems are related to
maximum width of a character, and since comments were up to 80 characters, so
why not use 80em. But, that does look way too wide.

Then searched, and I discovered that 'em' is technically is more related
to the height of the font-size, and that on average, the width of a wide
range of letters of typical fonts are 0.7em. So,

0.7em x 80 characters = 56 em

Hence, perhaps a little wider area is justifiable to fit the "average,
typical" monospaced fonts. In other words, most fonts at many zoom levels
can indeed fix most sequences of 80 characters in 50 em, but occasionally,
for a certain set of characters, a certain font, at a certain zoom level,
one might require 51, or 53 ... or even 56?

In my mini-test of '51em' I tried 2 or 3 fonts, and several zoom levels and
none of them "broke" inappropriately for my tiny test case. But, I did not
test systematically, and tested only on firefox. If anyone thought it worth it,
perhaps someone would be willing to test a wide range of fonts and a wide
range of (normal) zoom levels. By normal, I'd think -2, -1, 0, +1, +2 would
be common, where '0' is the "reset" value, and numerals represent number of
times for ctrl-- or ctrl-+.

Luckily, a couple of work arounds exist ... try different browsers, or try
different fonts until you find one that works well for your typical viewing.

Here's some references I found helpful:

[1] http://www.webmasterworld.com/forum83/5001.htm
[2] http://en.wikipedia.org/wiki/Em_%28typography%29
[3] http://jontangerine.com/log/2007/09/the-incredible-em-and-elastic-layouts-with-css

Thanks

Comment 28

[Max Kanat-Alexander]

Hey David. Thanks for that info! The point of the CSS class is to wrap CJK languages, and they actually already wrap considerably longer than the English text. Your logic sounds fairly sound, though, so if you want to post a patch and get it reviewed along with our development process, I'd possibly be willing to accept it. Our development process is here: 

  http://wiki.mozilla.org/Bugzilla:Developers

Also, make sure that comment 23 does not apply--that is, if we're taking the em-width of some other font, then that would be wrong.

Comment 30

[Max Kanat-Alexander]

Ben: What font are you using for monospace by default? (And what platform/browser are you on?)

Comment 31

[Ben Bucksch (:BenB)]

See bug 524795 comment 2:
Apparently, this is dependent on the font size. I have "monospace" 12 as
Monospace font in the FF font dialog, on SuSE Linux. If I increase or decrease
the font size in Firefox using Ctrl+mouse wheel, the bad wrapping is gone.

Comment 32

[Max Kanat-Alexander]

As of Bugzilla 4.2, comments are *only* wrapped using CSS, so this problem won't appear.