Bug in RT 3.8.0 display, when using fixed pitch font

OK, so this is a spam ticket, but it illustrates a problem with the
display of text/plain comments when the fixed pitch font option is
switched on. Without that option, the transaction displays fine, with
the text being wrapped where code sees fit. But with fixed pitch no
wrapping is performed; that in itself is not a problem, it’s what I’d
expect, but the scrollbar on the widget is set to the wrong size, and
runs off beyond the right edge of the window. I have a screenshot of
this which I will email to anyone who’s interested, but I won’t
clutter your inboxes with it now.

I also noted that the fixed pitch font used is using double line
spacing, which probably isn’t right. This was observed using both
Firefox 3 and Safari on a Mac, and IE 7 on Windows, so it seems to be
a browser-independent problem.

Regards,

Tim

The Wellcome Trust Sanger Institute is operated by Genome Research
Limited, a charity registered in England with number 1021457 and a
company registered in England with number 2742969, whose registered
office is 215 Euston Road, London, NW1 2BE.

OK, so this is a spam ticket, but it illustrates a problem with the
display of text/plain comments when the fixed pitch font option is
switched on. Without that option, the transaction displays fine, with
the text being wrapped where code sees fit. But with fixed pitch no
wrapping is performed; that in itself is not a problem, it’s what I’d
expect, but the scrollbar on the widget is set to the wrong size, and
runs off beyond the right edge of the window. I have a screenshot of
this which I will email to anyone who’s interested, but I won’t
clutter your inboxes with it now.

Trying to get HTML wrapping to do the right thing for non-breaking
plaintext email is one of the least fun things I’ve had to do in
recent years and experience tells me that getting it right across all
common browsers is…difficult. A patch would be quite welcome.

I also noted that the fixed pitch font used is using double line
spacing, which probably isn’t right. This was observed using both
Firefox 3 and Safari on a Mac, and IE 7 on Windows, so it seems to be
a browser-independent problem.

Noted. I’ve opened a ticket for this one.

Best,
Jesse