Closed Bug 187255 Opened 22 years ago Closed 20 years ago

window.open() not blocked in linked script loaded after document.close()

Categories

(SeaMonkey :: General, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: faith, Assigned: danm.moz)

References

()

Details

(Keywords: testcase)

Attachments

(1 file, 1 obsolete file)

381 bytes, text/html
Details
User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20021226
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.3b) Gecko/20021226

It appears they're using a different method than the one blocked to get the
windows to popup.  Surprised the heck out of me!

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
They are using onload with setTimeout in an invisible frame after 3 secs to call
a jscript function which loads the popup.  The frame address is
http://www.myeremco.com/lander/pop.php.  Just to confuse things, it also loads a
24hr cookie to stop the popup appearing again.

Here's the frame source:

<html>
<!-- ---------- Advertising.com Banner Code -------------- -->
<script language="JavaScript">
<!--
function setCookie(NameOfCookie, value, expirehours) {
  var ExpireDate = new Date ();
  ExpireDate.setTime(ExpireDate.getTime() + (expirehours * 3600 * 1000));
  document.cookie = NameOfCookie + "=" + escape(value) +
  ((expirehours == null) ? "" : "; expires=" + ExpireDate.toGMTString()) +
  "; path=/;" ;
}

function advertiseMe() {
  if (document.cookie.indexOf('AdComPop72143')==-1)
    {
      setCookie('AdComPop72143','yes',24);
      var bnum=new Number(Math.floor(99999999 * Math.random())+1);
      document.write('<SCR'+'IPT LANGUAGE="JavaScript" ');
      document.write('
SRC="http://servedby.advertising.com/pops=6/site=72143/bnum='+bnum+'">');
      document.write('</SCR');
      document.write('IPT>');
    } else {
      window.open('http://munky.com/munkypop3.php',
		  'munkypop',
		  'height=250,width=500');
      window.focus();
    }
}

// -->
</script>
<!-- ----------Copyright 2000, Advertising.com---------- -->
<body  OnLoad="window.setTimeout('advertiseMe()', 3000)">
</body>
</html>
ive also spotted this new method, here is another example 

http://www.popupad.net/example.shtml
We should be blocking window.open from inside a setTimeout....
right out of the http://www.mozilla.org/unix/customizing.html#prefs

// It is now possible to disable the JavaScript window.open() method
// when it is not called as a result of a mouse click.
// When the dom.disable_open_click_delay pref is set to a non-zero
// number, window.open will fail when called more than that number
// of milliseconds after a mouse click.
user_pref("dom.disable_open_click_delay", 1000);

wfm with this pref
I tried the pref in Win98.  Result?  No popup appeared.

However ... the throbber never stopped and the status remained forever at
'Transferring data from ...", so I would say the preference doesn't quite work
right.  Is this an different existing bug?

More as Boris says, I think this type of popup should be stopped by the existing
UI preference.  It is clearly an unsolicited popup window, not the result of a
mouse click and should be blocked.
I see it. A more condensed test case derived from comment 1 (thanks ian!):

<html><head><script>
function popup() {
  document.write('<'+'script src="187255-script" </'+'script>');
  document.close();
}
</script></head><body onload='setTimeout(popup,1000)'>
these original contents will be overwritten
</body>

where the file "187255-script" is:

open('about:blank','_blank','height=200,width=300')

also demonstrates the problem. By the time Mozilla executes the script added by
document.write the timeout function has already finished running and Mozilla
thinks the document has finished loading. So it doesn't realize the new window
is a popup and doesn't try to block it. Interesting though: reload the page and
the popup /is/ blocked. (Both this test case and the advertising.com source
behave this way.) When reloaded for some reason Mozilla thinks the document has
/not/ finished loading, so it recognizes the new window as a popup. That makes
me think the code path to fix this already exists; it just needs to be brought
out in the original page load case.

Less encouraging observation: setTimeout isn't necessary. In the testcase above,
change

<body onload='setTimeout(popup,1000)'>

to

<body onload='popup()'>

and Mozilla always thinks the document has already finished loading when the
request for the new window comes around. That's kinda surprising. Once more: use
setTimeout and sometimes the document is still loading at window.open time; open
the popup window immediately without setTimeout and the document has always
finished loading come window.open time.

Icky. Wants fixing.

(By the way, the unending throbber mentioned above (comment 5) will stop
throbbing if you call document.close(), as in my examples, so that's a different
problem.)
Assignee: asa → danm
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Popups appear -- I have them disabled under my Preferences. → advertising.com's document.write popup windows aren't blocked
*** Bug 188037 has been marked as a duplicate of this bug. ***
Attached file Testcase.
Not 100% sure if this testcase belongs here, noticed this when I was doing this
testcase for bug 190588. This testcase writes content with javascript into an
iframe (no timer used).
How about refrasing the bug that using document.write to creates unblockable
popups, or should i file a new bug for that?
Blocks: popups
Summary: advertising.com's document.write popup windows aren't blocked → document.write popup windows aren't blocked
I think www.giveboobs.com may contain another variant of this (ominously popping
up to a big ad website at http://www.popupad.net/ats/route.php). (The referenced
site is safe to check out, it's not a pr0n site but rather something that popped
up :-) in the news recently about a college girl trying to raise money for
cosmetic surgery).

I've just noticed this is another example of comment 2, but I'm not sure it's
the same issue as the original report. 

Anyway, here's more info on this... The following code appears in the header:

--- Start of code from <head> section ---
<script language=JavaScript>
<!--//
function loadpopup()
{
document.flauncher.submit();
focus();
setTimeout('focus()',2000);
}
// -->
</script>
--- Start of code from <head> section ---

This is followed up by an onload() call and a form in the body that pops up the
add when submitted.

--- Start of code from body ---
<body background="brownback.gif"  leftmargin=0 marginwidth=0 topmargin=0
marginheight=0 onLoad='loadpopup()'>

[...]

<form name='flauncher' action='http://www.popupad.net/ats/switch.php'
target='adv' method='post' onSubmit='focus();'>
<input type='hidden' name='id' value='6362'>
</form>
--- Start of code from body ---
Keywords: testcase
*** Bug 210474 has been marked as a duplicate of this bug. ***
Tweaking summary to catch more dupes
Summary: document.write popup windows aren't blocked → document.write and window.open from inside a setTimeout popup windows aren't blocked
Tweaking summary even more
Summary: document.write and window.open from inside a setTimeout popup windows aren't blocked → document.write, window.open from inside a setTimeout and body / form onload popup windows aren't blocked
Tweaking back - sorry for the spam
Summary: document.write, window.open from inside a setTimeout and body / form onload popup windows aren't blocked → document.write and window.open from inside a setTimeout popup windows aren't blocked
Ray (comment 10): the form submission bug actually isn't a variant of this one.
Besides the different testcase, internally the problem is very different. Thanks
for finding that, though. I've split it off into a new bug 210560.
OS: Windows 98 → All
Hardware: PC → All
Summary: document.write and window.open from inside a setTimeout popup windows aren't blocked → window.open() not blocked in linked script loaded after document.close()
No longer blocks: popups
Attached file Another testcase? (obsolete) —
I've found another way to do about the same thing, it is used on
http://www.aol.com. It seems to be the same bug - if not I can open a separate
bug on it. The strange thing is that it doesn't work with inline JavaScript
nodes, you have to specify an URL to load the script from that will open the
popup (I'm using a javascript: URL only for convenience, AOL has a normal http:
URL).
The aol.com technique is bug 252326, please keep the issues separate to make
sure to avoid partial fixes.
Blocks: 253780
Attachment #154987 - Attachment is obsolete: true
*** Bug 255959 has been marked as a duplicate of this bug. ***
Firefox now appears to correctly block the testcase's pop-up as expected.
Probably due to the fix in Bug 252326.

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040908 Firefox/0.10
Also WFM: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040909
Firefox/0.10

Marking it as WORKSFORME.
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.