Closed Bug 291550 Opened 19 years ago Closed 17 years ago

Page does not display correctly

Categories

(Core :: Layout: Tables, defect)

Product:
Core
Component:
Layout: Tables
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: mozilla, Unassigned)

References

(
URL
)

Details

(Keywords: testcase)

Attachments

(4 files, 1 obsolete file)

testcase seen in Mozilla, 800x600
48.53 KB, image/png
Details
testcase seen in Opera, 800x600
48.90 KB, image/png
Details
Minimized testcase
623 bytes, text/html
Details
independent testcase
730 bytes, text/html
Details 
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
2.
3.

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.
Assignee: firefox → nobody
Component: General → Layout
OS: Windows XP → All
Product: Firefox → Core
QA Contact: general → layout
Hardware: PC → All
Version: unspecified → Trunk
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
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
"correct."

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
Attached file testcase (obsolete) — 
The original page has a 1024px wide gif as background specified in <body>:
http://www.usps.org/localusps/wilm/background.gif

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"
height="44"><tr> 
  <td width="127" height="34" valign="top" align="center"><p><font
color="#FFFFFF"><b>Home</b></font></p></td>
  <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"
height="18">
		<hr width="586">
		</p>
  </td>
  <td width="59" height="21"></td>
</tr></table></div>

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.
Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8b2) Gecko/20050423

confirming
Status: UNCONFIRMED → NEW
Component: Layout → Layout: Tables
Ever confirmed: true
Keywords: testcase
QA Contact: layout → layout.tables
Attached file Minimized testcase — 
Bit smaller testcase. adding empty-cells:show; to the td "fixes" the issue.
Attachment #181650 - Attachment is obsolete: true
Attached file independent testcase — 
replaced remote image with <hr>, added empty-cells: show; unified td's.

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

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
I found a bad page by Mozilla 1.7.7 on Win XP
http://www.tat.com.tw/ 
I think we already have bugs on completely ignoring some widths once we're
overconstrained with too much width on the cells...
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
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: