Closed Bug 98654 Opened 21 years ago Closed 21 years ago Pop-up ads appear blank


(Core :: DOM: Core & HTML, defect, P1)






(Reporter: rituraj_tiwari, Assigned: jst)




(Keywords: topembed+, Whiteboard: [HAVE FIX][FIXED ON TRUNK][adt1][m5+] [ETA 04/29])


(2 files)

Seen on build Id 2001090603:
The pop-under ad window on the URL above comes up blank (not that I mind not 
seeing ads). Since this ad is displayed only once over a certain period, the Y! 
cookie needs to be cleared out in order to reproduce the problem.

Summary: Pop-under ads don't show up → Pop-under ads appears blank
Reporter Is this a problem with 0.9.4 or later ?
Still broken on build 2001100708
confirming with win2k build 20011008..
-> Dom0 (?)
Assignee: asa → jst
Component: Browser-General → DOM Level 0
Ever confirmed: true
QA Contact: doronr → desale
*** Bug 107811 has been marked as a duplicate of this bug. ***
Copied from my dupe bug. I emailed Yahoo but it would nice to know where the bug

Go to or (Note: They do not
serve the ads after a certain amount of accesses...not sure
if within a session or a time period, so you'd need to clear the cookies...I
think, if you need to replicate multiple times in a short time period.)

The pop up window is supposed to have ad content.
1) The status bar says "connecting to" yet the page never loads
2) The popup is blank but source has


80% of the time.
This occurs no matter what my connection speed, using Gecko/20011019. 

Replicated on Win 2000 and Win 98.

I saw this too the one time I got a popup ad from one of the yahoo sites, but I
didn't get one again so I couldn't track it down further...
Found another example:
1. go to
2. Click "funny" under the Birthday category

Result: Popup ad from is blank

To replicate you have to delete your cookies (or some amount of time has to pass
before it pops up again...not sure of their method).
I emailed Yahoo again to see if they can figure out what the problem is.
Added Yahoo to summary line; is this not an evang issue until proven otherwise
or is it a known product issue? If evang please recategorize.
Summary: Pop-under ads appears blank → WWW.YAHOO.COM Pop-up ads appear blank
***Need someone to look at this*** to know if it is an evangelism issue or not.
Still occurs on all recent builds. This time on the source code
of the blank popup is: <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01

The status bar is always left at "Connecting to"

I have emailed Yahoo customer service twice about this but have not directly
spoken to them until we know where the issue may lie.
Keywords: qawanted
Here is the part I don't get: If this works with IE and does not work with 
Mozilla, why would it be a Yahoo bug? Unless of course they are sending the 
page in a non-stanards-compliant way which I am sure can be easily verified if 
such is the case. I can't understand how Y! customer service can help in this 
matter at all?

In case it is the case that "Unless of course they are sending the page in a
non-stanards-compliant way" or that the content is being served in a non
compliant way. (I'm not technical enough to know but posed it as a possibility.)
I am really not familiar with the Mozilla bug process but shouldn't the engineer
assigned to this bug (JST) be trying to access the pop-under pages using a tool
like wget or such to find out where the problem lies? I still don't see how Y!
customer service will help. You guys can reproduce this problem in house and if
its a Y! issue, you let them know.

Yes, I should be doing something like that, and I will be doing something like
that once I get there. This problem is just not close to the top of my list of
things to do yet. Not sure when I'll get to it. Any help of any kind is greatly
appreciated, as always.
perhaps related to bug 103757
 when I go to and the popup comes up:
1) still is blank with "Sending request to" in the bottom status bar
2) the address bar in the popup window says wyciwyg://1//
3) the source code only has </head><body></body></html>

Reload does not cause the ad content to load.

Build Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.8+) Gecko/20020213 

There is going to be a flood of similar, often hard to analyse cases where pages
do not load, due to the new "wyciwyg://" URL scheme - or not.
I feel sorry for the Netscape engineers who are asked to respond to the failures
of these cases without participation of the website's designers.
I would personally not waste any time on this particular case yet.

I am in charge of a multitude of web sites where Mozilla definitely fails
completely and for the single cause of a tiny side effect of this new scheme.

I have a created a testcase that pinpoints exactly what the problem is.

Before trying to analyse this problem on multiple other sites, I am suggesting
to reap the benefits of the analysis that has been done already.

Please refer to the testcase in bug 125003.

I am confident that a lot of these "wyciwyg://" problems whether they are
diagnosed as such or not will disappear after bug 125003 is fixed.

IMHO this bug is a big and critical thing and a lot of unnecessary work can be
saved by fixing it asap.
Severity = MEDIUM [No Crash, functional failure is there, Can Result in Cosmetic 
failure too]
Visibility = HIGH [Great deal of real world website usage, Gets one point of 
compatibility with other browsers since it works on other browsers. gets one 
more point on compliance with adopted techonology, that is JS] 

Priority = Visibility * Severity

Priority = p2
But since lot of visibility is there, given that pop-up ads apear blank, pushing 
it up one more step.
Priority = p1

if someone feels otherwise then please investigate this more & feel free to 
change this priority.
Priority: -- → P1
cc'ing mgalli to add more info.
He has identified the exact bug, and has gotten a workaround to Yahoo. 
mgalli, if you know anything more about this, would you explain what the deal is
here? Thanks.
*** Bug 129729 has been marked as a duplicate of this bug. ***
Hi Johnny, 

I don't know if this case have more issues (it's sort of confuse), but here is
the thing I found: I filed bug 129729 which have a simple testcase for one
problem I found there. 

The yahoo code is using JS to:

1) Create a new window
2) document write (into the new window) CONTENT.
3) CONTENT is mostly JS window.location="http://somepage".

The results are: 

window.location is not working.

The workaround is: 

in step 3), script window.location inside one function and call the function in
the onload event. 

removed capitals from summary - 

can we confirm, is this a evang bug, or is gecko being a naughty lizard?
Summary: WWW.YAHOO.COM Pop-up ads appear blank → Pop-up ads appear blank
Yahoo's trying to implement a fix in their code, but marked this
topembed/nsbeta1 with hopes of someone looking at if this is a bug.
Keywords: nsbeta1, topembed
Let me see if I can come up with anything. This is an area where web authors
have a very difficult time. Comment #22 is interesting and it indicates to me
that the Yahoo authors are facing a dilemma.
I have been familiar with an IE issue that is as old as the browser itself.
The Yahoo code is probably partly a workaround for this.

In all versions of IE, the js code "" does not block and in 5-10%
of all cases IE gets js security errors on attempts to access ANY properties of
the new window simply because the returned window object is not ready. Setting
window.location on a pup-under window is probably not an easy thing to do
cross-platform. I have seen this on other sites also not only Yahoo.

If Netscape declares this an evangelism issue or does not fix this then the
perception in business people who make a living with web based applications will
grow that their business can be destroyed by a new browser release at any time.

The options they are looking at times are flash, downloadable code such as java
web start, curl, IE-only etc.

So far, Nescape has been a very good citizen in the area of window handling and
I am not aware of any major bug in version 4  but what worries me is this bug
and much more seriously bug 131841. Those things did not exist in Netscape
version 3 and 4.
Target Milestone: --- → mozilla1.0
I've been trying to see what the problem really is here and it's extremely hard
to debug this since getting to show those popups more than once or
twice is really hard, removing cookies n' all that doesn't help. I'm kinda stuck
here, I think I have an idea about why this doesn't work, and I would love to
fix this for mozilla1.0, but I'd really appreciate some debugging aid here.
Ideally someone would know of a site that shows this same problem every time
it's loaded, that would help greatly.
Keywords: topembedtopembed+
If anyone's able to test the fix on on an embedded browser to see if
the site comes up (instead of being blank), that would be great.
Comment on attachment 77564 [details] [diff] [review]
This should fix this...

Why do you call htmldoc->EndLoad() again at the end of the termination
function? EndLoad() calls a function that calls EndLoad() again?
Comment on attachment 77564 [details] [diff] [review]
This should fix this...

Vidur says sr=vidur.
Attachment #77564 - Flags: superreview+
Attachment #77564 - Flags: review+
Comment on attachment 77564 [details] [diff] [review]
This should fix this...

Johnny, please land this on the trunk.  Following QA verification, mark with
keyword ADT1.0.0 and email requesting approval to land on the
Fix checked in on the trunk.
OS: Windows NT → All
Hardware: PC → All
Emailed adt to seek approval for checkin to branch.
gerardok - can you make sure this gets verified?  prashant is on vacation.

[adt1]/nsbeta1+, as we need to serve up sites ads correctly.
Keywords: nsbeta1approval, nsbeta1+
Whiteboard: [HAVE FIX][FIXED ON TRUNK] → [HAVE FIX][FIXED ON TRUNK] [adt1] [Need a=]
Whiteboard: [HAVE FIX][FIXED ON TRUNK] [adt1] [Need a=] → [HAVE FIX][FIXED ON TRUNK] [adt1][m5+] [Need a=]
Comment on attachment 77564 [details] [diff] [review]
This should fix this...

a=asa (on behalf of drivers) for checkin to the 1.0 branch
Attachment #77564 - Flags: approval+
Whiteboard: [HAVE FIX][FIXED ON TRUNK] [adt1][m5+] [Need a=] → [HAVE FIX][FIXED ON TRUNK][adt1][m5+]
Verified fix checked in CVS (rev 3.422),the above testcase and valid URL's in
this bugs passes in the build ID on 2002042209(trunk) using winXp
Sounds  like this has been verified by QA on the trunk. If yes, pls Verify this
one as Fixed.

adt1.0.0+ (on ADT's behalf) approval for checkin to the 1.0 branch. Pls check
this in today, then add fixed1.0.0 keyword.
Keywords: adt1.0.0+
Whiteboard: [HAVE FIX][FIXED ON TRUNK][adt1][m5+] → [HAVE FIX][FIXED ON TRUNK][adt1][m5+] [ETA 04/29]
Fixed on the branch now too.
Closed: 21 years ago
Keywords: fixed1.0.0
Resolution: --- → FIXED
Verified fixed in Gecko/20020507
(Yahoo popup that was previously blank now shows the ad)
*** Bug 55213 has been marked as a duplicate of this bug. ***
verified1.0.0 on 05-22-18-1.0.0 & also Verified on trunk on 05-23-08-trunk.
Keywords: verified1.0.0
Keywords: qawanted
You need to log in before you can comment on or make changes to this bug.