252347 - multiple lines of text rendered on top of each other

Status: RESOLVED WORKSFORME

(Bugzilla :: Attachments & Requests, defect)

Description

[David Most]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040707 Firefox/0.9.2

There are two problems with the rendering of the following URL.  The first is
that on the "box on the right", one line of text is drawn on top of another line
of text.  The second issue, is that the same line of text extends beyond the
"border" of the box that is supposed to be containing it.  I suspect both issues
are in fact the same and related to the text not being "clipped" to the bounding
box it is in.

http://bugzilla.mozilla.org/attachment.cgi?oldid=127939&action=interdiff&newid=128426&headers=1#viewcvs.py.bak_sec2
Search for the string: re.compile('((http|ftp)(://

This issue also occurs in Mozilla:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113

I have attached a screenshot (saved as 16 color to save some space).

Reproducible: Always
Steps to Reproduce:
1.Launch Firefox
2.Go to URL:
http://bugzilla.mozilla.org/attachment.cgi?oldid=127939&action=interdiff&newid=128426&headers=1#viewcvs.py.bak_sec2


Actual Results:  
Noticed text drawn over text

Expected Results:  
Crop text to table boundary

Comment 1

[David Most]

Attachment: small screenshot illustrating the defect

Comment 2

[Boris Zbarsky [:bzbarsky]]

> I suspect both issues are in fact the same and related to the text not being
> "clipped" to the bounding box it is in.

That's true.  Nor should they be, given the markup and style on that page.

Not a layout bug.  Over to bugzilla in case they want to put some overflow
styles on things.

Comment 3

[Mats Palmgren (inactive)]

It's a very long word wrapped in <PRE> - I think word-breaking that would be
wrong. Given that, the layout is correct.

There are two problems I can see though:
1. when no horizontal scrollbar is present, the end of the overflow is
   *under* the vertical scrollbar (related to bug 44192 or bug 47710?).
2. the overflow is not repainted when scrolling with the horizontal scrollbar.
   (bug 247807?)

I assume we have bug reports on both of these?

Comment 4

[Max Kanat-Alexander]

I don't currently see this problem.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Uh.... How wide is your browser window?  At a window width of 1000px or so, and with default fonts, the URL from comment 0 shows the problem just fine.

This is a constant issue when using the bugzilla interdiff; half the time it makes the diffs unreadable for me.

Comment 6

[Boris Zbarsky [:bzbarsky]]

Max, see comment 5.

Comment 7

[Max Kanat-Alexander]

(In reply to comment #5)
> Uh.... How wide is your browser window?  At a window width of 1000px or so, and
> with default fonts, the URL from comment 0 shows the problem just fine.

  I don't see any overlapping lines in Firefox 3 here with that URL, no matter how small I make the window. I do see that single-word text expands beyond the boundaries, but that's a well-known browser issue, not some problem with Bugzilla.

Comment 8

[Boris Zbarsky [:bzbarsky]]

The text in the first column runs into the second column and overlaps the text there, making it unredable.

> but that's a well-known browser issue, not some problem with Bugzilla.

The browser is rendering the markup exactly how your CSS asks it to be rendered.  So in fact, the rendering is a problem with the HTML and CSS Bugzilla uses, unless this is the rendering Bugzilla wants here.  You did read comment 2, right?

Comment 9

[Max Kanat-Alexander]

(In reply to comment #8)
> The text in the first column runs into the second column and overlaps the text
> there, making it unredable.

  Yeah, I've seen that happen in patches, I just can't reproduce it at the link in comment 0.

> The browser is rendering the markup exactly how your CSS asks it to be
> rendered.

  Mm, no, our CSS is -moz-pre-wrap (or pre-wrap for CSS3), so the browser is not doing what we asked, if it overlaps.

>  So in fact, the rendering is a problem with the HTML and CSS
> Bugzilla uses, unless this is the rendering Bugzilla wants here.  You did read
> comment 2, right?

Comment 10

[Boris Zbarsky [:bzbarsky]]

> I just can't reproduce it at the link in comment 0.

Really?  Line 347?

>  Mm, no, our CSS is -moz-pre-wrap (or pre-wrap for CSS3)

Where, exactly?  Here's the markup on the page:

   <td class="num">347</td>
   <td><pre> long line of text here </pre></td>

The <pre> has the following CSS applied to it by the page:

  font-size: medium;  /* From skins/custom/global.css */
  display: inline; font-size: 0.9em;  /* From the inline stylesheet */

It also has a "white-space: pre" coming from the UA stylesheet.  No pre-wrap anywhere in evidence.

Comment 11

[Max Kanat-Alexander]

(In reply to comment #10)
> > I just can't reproduce it at the link in comment 0.
> 
> Really?  Line 347?

  Yeah, really.

> It also has a "white-space: pre" coming from the UA stylesheet.  No pre-wrap
> anywhere in evidence.

  No, firebug says it's pre-wrap. Do you have the wrong stylesheets cached or something?

Comment 12

[Mats Palmgren (inactive)]

Bug 433065 dropped support for -moz-pre-wrap.

tbody.file pre {
  display: inline;
  white-space: -moz-pre-wrap;
  font-size: 0.9em;
}

That rule needs a white-space:pre-wrap too.

Comment 13

[Max Kanat-Alexander]

(In reply to comment #12)
> That rule needs a white-space:pre-wrap too.

  It has one, we already have fixed that.

Comment 14

[Boris Zbarsky [:bzbarsky]]

That change doesn't seem to have ended up on bmo yet, I guess...

Comment 15

[Boris Zbarsky [:bzbarsky]]

Because the inline stylesheet on the page in comment 0 certainly doesn't have a pre-wrap in it.

Comment 16

[Max Kanat-Alexander]

I'm checking it on bmo, and Firebug says the pre-wrap is definitely there, and it definitely still works for me after a shift-refresh.

Comment 17

[Mats Palmgren (inactive)]

Max, Firebug is incorrect.  FF3 supports both -moz-pre-wrap and pre-wrap,
if *either* is used Gecko will serialize the value as "pre-wrap" even though
the rule actually uses "-moz-pre-wrap".  Firebug just uses the serialized
value that Gecko gives it.  So the bug is definitely in the rule used
at b.m.o.

> it definitely still works for me after a shift-refresh

In a trunk build?

Comment 18

[Boris Zbarsky [:bzbarsky]]

Max, Firebug is lying to you.  And if you're not using a recent trunk build you won't see the problem, as Mats says.  Seriously, just do a view-source of the page you're looking at instead of trusting Firebug.

Comment 19

[Boris Zbarsky [:bzbarsky]]

Heck, just look at the page in a browser that supports pre-wrap but not the non-standard -moz-pre-wrap (trunk Firefox would work, but also Safari or Opera).

Comment 20

[Max Kanat-Alexander]

You are both reporting bug 460749, which is not originally this bug. We've fixed that upstream. This bug itself was effectively fixed long ago for most browsers.