Closed
Bug 252347
Opened 20 years ago
Closed 16 years ago
multiple lines of text rendered on top of each other
Categories
(Bugzilla :: Attachments & Requests, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: david_most, Unassigned)
References
()
Details
Attachments
(1 file)
171.68 KB,
image/bmp
|
Details |
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•20 years ago
|
||
Updated•20 years ago
|
Assignee: firefox → nobody
Component: General → Layout
Product: Firefox → Browser
QA Contact: firefox.general → core.layout
Version: unspecified → 1.7 Branch
Comment 2•20 years ago
|
||
> 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
Comment 3•20 years ago
|
||
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•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Updated•18 years ago
|
Assignee: myk → attach-and-request
Comment 4•16 years ago
|
||
I don't currently see this problem.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
Comment 5•16 years ago
|
||
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•16 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.
Comment 8•16 years ago
|
||
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•16 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?
Comment 10•16 years ago
|
||
> 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•16 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?
Comment 12•16 years ago
|
||
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•16 years ago
|
||
(In reply to comment #12) > That rule needs a white-space:pre-wrap too. It has one, we already have fixed that.
Comment 14•16 years ago
|
||
That change doesn't seem to have ended up on bmo yet, I guess...
Comment 15•16 years ago
|
||
Because the inline stylesheet on the page in comment 0 certainly doesn't have a pre-wrap in it.
Comment 16•16 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
Closed: 16 years ago → 16 years ago
Resolution: --- → WORKSFORME
Comment 17•16 years ago
|
||
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•16 years ago
|
||
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 → ---
Comment 19•16 years ago
|
||
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•16 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
Closed: 16 years ago → 16 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•