If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Page does not display correctly




Layout: Tables
13 years ago
11 years ago


(Reporter: Lu Abel, Unassigned)




Firefox Tracking Flags

(Not tracked)




(4 attachments, 1 obsolete attachment)



13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

The above URL (http://www.usps.org/localusps/wilm/wpsedu.htm#Top) displays
correctly in IE.  In Firefox, the type sizes are larger than those displayed in
IE, causing the material to "leak" into the left-hand column.  Looks like
Firefox and IE have different interpretations of "font size=4" and "big" 

Reproducible: Always

Steps to Reproduce:
1.Simply go to url given above

Actual Results:  
Saw the bad display

Expected Results:  
While I realize I may be starting a religious war of "correctness," it looks
like IE  and Firefox interpret the type size directives differently, causing the
page under Firefox to display differently (and visually incorrectly) as compared
to IE.


13 years ago
Assignee: firefox → nobody
Component: General → Layout
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: PC → All
Version: unspecified → Trunk

Comment 1

13 years ago
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b2) Gecko/20050412
Firefox/1.0+ (nightly)

Do you have a shorter testcase, and perhaps any guidance from standards as to the
correct render?

I didn't see any leaking or dependency on fontsize.

Gecko does have layout bugs, and if this is one of them it will be investigated 
and fixed

Comment 2

13 years ago
Respectfully, I'm a user, not a developer.  Firefox is amazingly good given the
diversity of stuff crammed into web pages these days.  I just noticed this
particular page didn't look right under Firefox and compared the rendition to
that from IE.  

Without getting into a religious argument about "correctness," most page
developers will look at their results using IE and if it looks good they
publish.   So I respectfully submit that Mozilla has to treat IE's rendering as

We may be using "leaking" differently.  This page has a top-level navigation
menu down a narrow strip on the left hand side, with the specific page occupying
the rest of the space.   It's not done using frames, but simply by page layout.

When I look at the page using Firefox, the type in the "specific" page is larger
than it is under IE.  This in turn causes that portion of the page to be wider
than the author intended, with the left edge of the page starting within the
top-level navigation strip on the left with its background GIF.

I don't have a shorter example; I'm not the author of the page.  But a quick
glance at the source code (and I am NOT a deep HTML expert) leads me to guess
that it can be trimmed not too far below the line that says "Middletown High
School" and (plus or minus the </xxx> tags that might be deleted) you'd get a
pretty good test case.

Lu Abel

Comment 3

13 years ago
Created attachment 181650 [details]

The original page has a 1024px wide gif as background specified in <body>:

There is one div containing a table with 4 td's, the first one contains teh
navigation links, the third one the content, the second and fourth are empty.

<body background="background.gif">
<div><table border="0" width="800" cellspacing="0" cellpadding="0"
  <td width="127" height="34" valign="top" align="center"><p><font
  <td width="50" height="221"></td>
  <td width="460" valign="top" align="left" height="221"> 
	<p align="left"><font face="Arial, Helvetica, sans-serif">This course
	    is the second part of the study of offshore navigation. </font></p>

	<p align="left">
		<img src="ruler.gif" alt="ruler.gif (1k bytes)" width="586"
		<hr width="586">
  <td width="59" height="21"></td>

The third td is specified 460 px wide, but as it contains images which are
wider, it is expanded, and the neighbouring empty tds are collapsed.
I copied this div and removed the hr and the image, and the 1st td grows by
20px, the 2nd and 4th are shown.
I assume there is something wrong with the table.

Comment 4

13 years ago
Created attachment 181651 [details]
testcase seen in Mozilla, 800x600

Comment 5

13 years ago
Created attachment 181653 [details]
testcase seen in Opera, 800x600

Comment 6

13 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050423

Component: Layout → Layout: Tables
Ever confirmed: true
Keywords: testcase
QA Contact: layout → layout.tables

Comment 7

13 years ago
Created attachment 181688 [details]
Minimized testcase

Bit smaller testcase. adding empty-cells:show; to the td "fixes" the issue.


13 years ago
Attachment #181650 - Attachment is obsolete: true

Comment 8

13 years ago
Created attachment 181693 [details]
independent testcase

replaced remote image with <hr>, added empty-cells: show; unified td's.

<table width="600" cellpadding="0">
	<td width="100"></td>
	<td width="100"></td>
	<td width="100"><hr width="350"></td>
	<td width="100"></td>

First table has hr width 350, second table hr width 250, third has no hr.
1st table:  tr = 598, td = 99 + -1 + 349 + -1
computed style shows 349px for the 3rd div, so there is 251 left for the other
three, that is less than the sum of their nominal widths.
computed style for the 2nd and 4th div: -1px if empty-cells: show; specified,
else -2px. 

2nd table: tr = 599, td = 108 + 108 + 270 + 105
computed style shows 270px for the 3rd div, so there is 330 left for the other
three, there is some margin to be distributed.

3rd table: tr = 599, td = 148 + 148 + 148 + 147

Comment 9

13 years ago
I found a bad page by Mozilla 1.7.7 on Win XP
I think we already have bugs on completely ignoring some widths once we're
overconstrained with too much width on the cells...

Comment 11

11 years ago
All three tables render to the same size. Resolving as WFM unless someone wants to track down the actual bug that fixed this. 

Works for me on Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a5pre) Gecko/20070531 Minefield/3.0a5pre
Last Resolved: 11 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.