Closed Bug 102865 Opened 24 years ago Closed 24 years ago

background left side banner image is overlapped by table

Categories

(Core :: Layout: Images, Video, and HTML Frames, defect)

Product:
Core
Component:
Layout: Images, Video, and HTML Frames
Platform:
x86
Windows 2000
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED WORKSFORME

People

(Reporter: mozbugz, Assigned: attinasi)

References

(
URL
)

Details

(Keywords: verifyme)

Attachments

(6 files)

buffer.gif image shot in ns6.1 shows the size of the background image and where in starts in the main frame of page
94.53 KB, image/gif
Details
main body frame source (base href added)
15.78 KB, text/html
Details
header frame source
4.45 KB, text/html
Details
frameset using the pages from bugzilla.
362 bytes, text/html
Details
here is the page source for the body. (taken from the bugzilla attachment)
15.78 KB, text/plain
Details
page works in build 2001100610
106.49 KB, image/gif
Details
grey banner (background image file) on the left is not even displayed in ns6.1 and displayed properly in IE6 and it is only partially displayed in current nightlies on W2K. so its suppose to show the whole grey storagereview banner as part of body frame, but doesn't. this is not a problem on other pages of the site. I see the renderer correct until, then at the last second the whole table (not sure if table here or not source hard to come by?) gets shifted left overtop the image. There is a small spacer image (buffer.gif grey in color see attached shot taken in ns6.1).
site using doc type declaration here: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
*** Bug 102337 has been marked as a duplicate of this bug. ***
Confirming with fresh Linux CVS-I see the top frame overlapping the top part of the page (I only see the lower half of one of the grey buttons on the right).
Status: UNCONFIRMED → NEW
Component: Layout → HTMLFrames
Ever confirmed: true
When I pull the source for the body frame and load it by itself, it is fine. When it is part of the frameset, the left-edge banner is cut off. I'll attach the source for the main body frame now...
Status: NEW → ASSIGNED
Attached file header frame source —
Page looks fine when the frames are all served up from Bugzilla (or locally). Strange, maybe there is a timing issue with the server? I cannot get the site to server up just he body frame's page, so I'm not sure how that will look by itself off of their server. CC'ing karnaze for the table-foo.
see bug 98687 for info on loading body source pages.. I believe after sending an email to webmaster, it was taken offline and doesn't allow just loading of pages by themselves, mostly a JS, CSS loading problem.
opps should have entered plain text for that last attachment for .html to see the source like the view source document, correct?, as it comes out I see as the same attachment that Mark added for main body frame source (base href added). sorry, didn't figure that was going to happen.
Attachment #52006 - Attachment mime type: text/html → text/text
Attachment #52006 - Attachment mime type: text/text → text/plain
Updated the mime type for ya.
source for this index.jsp with problem page: <body bgcolor="#ffffff" marginheight="0" marginwidth="0" topmargin="0" leftmargin="0" rightmargin="0" link="#000080" vlink="#000080" alink="#800000"> <table border="0" cellspacing="0" cellpadding="0" width="100%" align="center"><tr><td width="1%" valign="top" background="images/sideline.gif"><img border=0 src="images/buffer.gif" width="35" height="5" alt=""></td><td width="99%"><table border="0" width="97%" align="center"><tr><td> source from main news.html that doesn't exhibit problem page: <body BGCOLOR="#FFFFFF" LEFTMARGIN="0" TOPMARGIN="0" MARGINWIDTH="0" MARGINHEIGHT="0"> <table BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <tr><td WIDTH="1%" VALIGN=TOP BACKGROUND="/images/sideline.gif"><img BORDER="0" SRC="/images/buffer.gif" WIDTH=35 HEIGHT=5 ALT=""></td> <td WIDTH="2%" VALIGN=TOP> <body BGCOLOR="#FFFFFF" LEFTMARGIN="0" TOPMARGIN="0" MARGINWIDTH="0" MARGINHEIGHT="0"> <table BORDER="0" CELLSPACING="0" CELLPADDING="0" WIDTH="100%"> <tr><td WIDTH="1%" VALIGN=TOP BACKGROUND="/images/sideline.gif"><img BORDER="0" SRC="/images/buffer.gif" WIDTH=35 HEIGHT=5 ALT=""></td> <td WIDTH="2%" VALIGN=TOP>
opps, got a double source paste there on the second one.
I am curious to weather there is a difference in the way mozilla renders the two pages based upon the way the source is coded with=# or with="#".. and the ordering of element variables on the code parser..
frameset header is using the doctype I had placed above... while in the frameset for the news.html page and others.. is: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN"> while the page in question here, is not using a doctype for the body frame page: so it is rendered in quirks-mode then, correct?
let me clarify that the header for the frameset is using the following doctype: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Frameset//EN"> while the body of the frame is different or None as my previous comment..
is it possible that changes to bug 102344 fixed this, because the page works in build 2001100610 W2K and it finally displays correctly.. cool!
I'd say this is fixed! anyone wanna change it?
funny, now it works in ns6.1 too and other mozilla builds.. i'd say wfm instead.
Keywords: verifyme
WFM based on reporters comments.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → WORKSFORME
Marking this big verified according to the reporter comments
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
Component: Layout: HTML Frames → Layout: Images
Product: Core Graveyard → Core
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: