Closed Bug 4564 Opened 26 years ago Closed 24 years ago

[LAYER] Banner add not showing up at mindspring.net

Categories

(Tech Evangelism Graveyard :: English US, defect, P3)

Product:
Tech Evangelism Graveyard
Component:
English US
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: paulmac, Assigned: bugzilla)

References

(
URL
)

Details

Attachments

(1 file)

isolated HTML code for ad banner; uses LAYER and document.layer
(deleted), text/html
Details
The banner add at the top of mindspring.net is not showing up in 4/5 builds of gecko (all platforms). It displays in I.E. 5.0 and 4.51. There is an IFRAME and Layers here. Perhaps it is choking there. Here is the not so small snippet. I will try to make it smaller tomorrow but I'm on the run. <html> <body bgcolor="#FFFFFF" vlink="#0000ff" alink="#ff0000" link="#0000ff"> <CENTER> <TABLE BORDER=0 CELLPADDING=3 CELLSPACING=0 BGCOLOR="#000066" WIDTH="100%"> <TR> <TD> </TD> <TD WIDTH=100%><CENTER> <NOLAYER> <IFRAME SRC = "http://ad.doubleclick.net/adi/mindspring.com/homepage;sz=468x60;cat=isp;cat=hom epage;ord=1" WIDTH=468 HEIGHT=60 MARGINWIDTH=0 MARGINHEIGHT=0 HSPACE=0 VSPACE=0 FRAMEBORDER=1 SCROLLING=no> <SCRIPT> </SCRIPT> </IFRAME> </NOLAYER> <NOSCRIPT> <A HREF = "http://ad.doubleclick.net/jump/mindspring.com/homepage;sz=468x60;cat=isp;cat=ho mepage;ord=1" WIDTH=468 HEIGHT=60> <IMG SRC = "http://ad.doubleclick.net/ad/mindspring.com/homepage;sz=468x60;cat=isp;cat=home page;ord=1" WIDTH=468 HEIGHT=60></A> </NOSCRIPT> <ilayer height=63></ilayer> </CENTER> </TD><TD> </TD></TR> </TABLE> </CENTER> </body> </html>
Assignee: troy → karnaze
Looks like an IFRAME problem
Status: NEW → ASSIGNED
Target Milestone: M6
Moving to M8.
Umm, this is not an IFRAME problem: In the test case (Apr05) above: (1) the IFRAME is inside a NOLAYER (2) the <A><IMG></A> is inside a NOSCRIPT (3) the ILAYER id=ph1 has no content So ... nothing _can_ show up in Gecko for the test case. However, one thing does follow at the end of the mindspring.net page: This bit of LAYER & script: <LAYER SRC = "http://ad.doubleclick.net/adl/mindspring.com/;sz=468x60;cat=isp;cat= homepage;ord=1" HEIGHT=60 VISIBILITY=hide ONLOAD="moveToAbsolute(ph1.pageX, ph1.pageY); clip.height=60; visibility='show';"> </LAYER> Supported by LAYER in Gecko? (Sorry, I don't know).
Assignee: karnaze → ekrock
Blocks: 8023
Status: ASSIGNED → NEW
The test case isolates the ad banner for www.mindspring.net. It fails to load in 5.0 on two counts: 1) <layer src> does not work (should it? I don't know) 2) it uses the document.layers API to move the content 'onload' (please correct me if I'm wrong). So, for (2), I'm passing this to ekrock and marking the dependency on the META bug for layer issues -- bug #8023 [Note: www.mindspring.net and the test case both look odd in Nav4.5 (contents of the <layer> are "displaced" to the right; however, that is the way the HTML is coded -- mindspring and doubleclick are just not in sync on what they are trying to achieve. Actually, this point alone would be good to evangelize, as, at first glance, it looks like a Netscape 4.x layout error -- and how many customers do they have? ... ;-) ].
Summary: Banner add not showing up at mindspring.net → [LAYER] Banner add not showing up at mindspring.net
Status: NEW → ASSIGNED
*** Bug 8989 has been marked as a duplicate of this bug. ***
This issue still occurs in the June 30th Build (all platforms).
Target Milestone: M8 → M15
Reassigning to M15 for tracking purposes only.
Here is some more information I've gathered from looking at www.redhat.com under mozilla: It seems that when getting URLS like: http://ad.doubleclick.net/jump/mindspring.com/homepage;sz=468x60;cat=isp;cat=ho mepage;ord=1 and http://ad.doubleclick.net/ad/www.redhat.com/index;hw=index;slot=2;tile=3;sz=125x125;ord=0DXXu86EKcsAAFkNQfM Mozilla actually retrieves http://ad.doubleclick.net/jump/mindspring.com/homepage;ord=1 and http://ad.doubleclick.net/ad/www.redhat.com/index;ord=0DXXu86EKcsAAFkNQfM respectively. On the second (redhat.com) case, this causes the wrong size image to be loaded, causing very ugly scaled animated gifs. Now, this isn't directly related to the blank banner ad at the top of the page, but it could be part of the cause.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → INVALID
INVALID. LAYER, ILAYER, document.layers[] not supported in Gecko/Nav5. Closed. Notified reporter and site owner via template at http://sites.netscape.net/ekrock/fixit/layer.html In the future, please INVALID, notify, and close such bugs directly using that template without assigning to me. Thanks!
Status: RESOLVED → VERIFIED
Marking as verified invalid
Moving all [LAYER] bugs to Evangelism component for tracking and open-source evangelism by mozilla community members of sites that need to upgrade to support web standards such as HTML 4.0 (instead of LAYER/ILAYER) and the W3C DOM (instead of Nav4 document.layers[] or IE document.all()). Sites should be lobbied to do the upgrade using the email templates that are linked to from http://www.mozilla.org/newlayout/bugathon.html#layerbugs . When a site's owner has confirmed receipt of the message requesting an upgrade, the bug should be marked with the keyword evangelized to indicate that evangelism for that bug is complete. When the site finishes the upgrade and supports standards, the bug should be closed.
Assignee: ekrock → nobody
Status: VERIFIED → NEW
Component: Layout → Evangelism
Keywords: evangwanted
QA Contact: petersen → nobody
Target Milestone: M15 → ---
Keywords: evangelized
Resolution: INVALID → ---
Marking bug evangelized and clearing cc:s as courtesy to reduce spam.
QA Contact: nobody → zach
SPAM:Changing QA contact on 111 evang bugs as I am now the new QA contact for this component. Sorry about the spam zach
Reassigning Evangelism bugs to me, the component's new owner. I would like to take this opportunity to thank nobody@mozilla.org for all of his dedication, contributions, and hard work, and wish him luck at his new job. Thanks, nobody.
Assignee: nobody → BlakeR1234
Removing the evangwanted keyword from 49 evangilizm bugs that also have the evangelized keyword. Having both of these keywords on a bug makes it really hard to do a query for all open evangilizm bugs that are evangwanted. Sorry for the spam.
Keywords: evangelized
Site fixed. Resolving as fixed.
Status: NEW → RESOLVED
Closed: 25 years ago → 24 years ago
Keywords: evangwanted
Resolution: --- → FIXED
verified OS9 2000092212
Status: RESOLVED → VERIFIED
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: