multiple lines of text rendered on top of each other

RESOLVED WORKSFORME

Status

()

Bugzilla
Attachments & Requests
RESOLVED WORKSFORME
14 years ago
10 years ago

People

(Reporter: David Most, Unassigned)

Tracking

2.17.6
x86
Windows XP

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

14 years ago
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
(Reporter)

Comment 1

14 years ago
Created attachment 153838 [details]
small screenshot illustrating the defect

Updated

14 years ago
Assignee: firefox → nobody
Component: General → Layout
Product: Firefox → Browser
QA Contact: firefox.general → core.layout
Version: unspecified → 1.7 Branch
> 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.
Assignee: nobody → myk
Status: UNCONFIRMED → NEW
Component: Layout → Attachments & Requests
Ever confirmed: true
Product: Browser → Bugzilla
QA Contact: core.layout → mattyt-bugzilla
Version: 1.7 Branch → 2.17.6
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?

Updated

12 years ago
QA Contact: mattyt-bugzilla → default-qa

Updated

12 years ago
Assignee: myk → attach-and-request

Comment 4

10 years ago
I don't currently see this problem.
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → WORKSFORME
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---

Comment 7

10 years ago
(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.
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

10 years ago
(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?
> 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

10 years ago
(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?
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

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

  It has one, we already have fixed that.
That change doesn't seem to have ended up on bmo yet, I guess...
Because the inline stylesheet on the page in comment 0 certainly doesn't have a pre-wrap in it.

Comment 16

10 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → WORKSFORME
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?
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.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
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

10 years ago
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.
Status: REOPENED → RESOLVED
Last Resolved: 10 years ago10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.