Closed Bug 3054 Opened 26 years ago Closed 26 years ago

[PP] :ea.com: Banner is repeated "Welcome to Electronic Arts"

Categories

(Core Graveyard :: Viewer App, defect, P2)

Product:
Core Graveyard
Component:
Viewer App
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: nbaca, Assigned: rickg)

References

(
URL
)

Details

Viewer.exe from 2/5/99. NT4, MAC 8.5, Linux. website: www.ea.com qa assign to chrisd@netscape.com Problem: NT, MAC. The banner at the top "Welcome to Electronic Arts" appears twice, one on top of the other. 4.5.1: NT and MAC show the banner once. Other 5.0: NT, MAC show banner twice. Linux shows two broken images in banner, will report this in a different bug.
Summary: PP:ea.com: Banner is repeated "Welcome to Electronic Arts" → [PP] :ea.com: Banner is repeated "Welcome to Electronic Arts"
Status: NEW → ASSIGNED
QA Contact: 1698
[QA Assigning to self.]
Appears to me to be a js error. Fails to write out a NOEMBED in the ea.com page and so it gets both the preferred and the default/noembed image in the page. <html><head></head><body> <HR> <SCRIPT> document.write('<NOEMBED>') </SCRIPT> using document.write of NOEMBED <BR> <IMG SRC="http://www.ea.com/images/ea_head.gif" WIDTH=475 HEIGHT=50 BORDER=0> </NOEMBED> <HR> <NOEMBED> not using document.write of NOEMBED <BR> <IMG SRC="http://www.ea.com/images/ea_head.gif" WIDTH=475 HEIGHT=50 BORDER=0> </NOEMBED> <HR> </body></html>
Uhh, to be clear on the *above* example, what it shows is that the document.write apparently fails. In the ea.com page, this means that the second image, that is intended to be wrapped in <NOEMBED></NOEMBED>, is instead unwrapped, and hence the duplicate display.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → WORKSFORME
unable to reproduce. can someone verify?
www.ea.com has changed the HTML that they were using to layout the page at the time this bug was filed. However, the test case noted above still applies (Apr 06 win95 opt nightly build). You can see the HTML above at http://qsilver.queensu.ca/~buslib/3054/3054.html
Status: RESOLVED → REOPENED
I guess I should re-open so you can have a look. If you want to close after looking at http://qsilver.queensu.ca/~buslib/3054/3054.html then that is fine.
Status: REOPENED → ASSIGNED
Target Milestone: M6
Turns out that the js is working fine. A design flaw in the parser prevents this from doing the right thing. I'll rework that piece of code and fix this problem.
Corrected by changes to parsing engine.
Status: RESOLVED → VERIFIED
This is verified fixed in today's build, as far as I can tell. John Morrison's test case passes on all 3 platforms, as does the actual EA site. [although the side issue noted to be broken into a separate bug is still present.] Thus, marking as Verified/Fixed. John, should you feel so inclined, please do feel free to double-check this, as you do so exceeding well. ;)
Double-check? How could I doubt the Master? However, there is no setting on Bugzilla for 'double-verified', so instead ... "I bless this bug as _healed_" (but you gotta say it with the right televangelist tone). [Tested win95 1999051709 (where I live these days) (Although what's the side issue that you refer to?).]
Ah, since *you* are the Master, there's no doubts here, either. ;) Speaking of thine mastership, thou hast once again noticed a problem. The side-issue (I assume nbaca broke it into 3056, not specified in bug; just the old animated GIFs on UNIX problem) is a different one Presently, the images that comprise the topnav.html frame aren't consistently loading when loaded as part of a frameset. (have seen this on Mac OS & Linux) I'm pretty sure there's already a bug on that (e.g. akkana's bug covering images not loading on the mozilla.org banner on occasional builds).
URL: www.ea.com → http://www.ea.com
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.