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)
SeaMonkey
General
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: faith, Assigned: danm.moz)
References
()
Details
(Keywords: testcase)
Attachments
(1 file, 1 obsolete file)
|
(deleted),
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.
|
||
Comment 1•22 years ago
|
||
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>
|
||
Comment 2•22 years ago
|
||
ive also spotted this new method, here is another example
http://www.popupad.net/example.shtml
|
||
Comment 3•22 years ago
|
||
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
|
|
||
Comment 5•22 years ago
|
||
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. ***
|
||
Comment 8•22 years ago
|
||
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).
|
|
||
Comment 9•22 years ago
|
||
How about refrasing the bug that using document.write to creates unblockable
popups, or should i file a new bug for that?
|
|
||
Updated•22 years ago
|
Summary: advertising.com's document.write popup windows aren't blocked → document.write popup windows aren't blocked
|
||
Comment 10•22 years ago
|
||
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 ---
|
||
Comment 11•21 years ago
|
||
*** Bug 210474 has been marked as a duplicate of this bug. ***
|
|
||
Comment 12•21 years ago
|
||
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
|
|
||
Comment 13•21 years ago
|
||
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
|
|
||
Comment 14•21 years ago
|
||
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
|
Assignee | |
Comment 15•21 years ago
|
||
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
|
||
Updated•21 years ago
|
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()
|
|
||
Updated•20 years ago
|
Blocks: pop-up-arms-race
|
||
Comment 16•20 years ago
|
||
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).
|
||
Comment 17•20 years ago
|
||
The aol.com technique is bug 252326, please keep the issues separate to make
sure to avoid partial fixes.
|
|
||
Updated•20 years ago
|
Attachment #154987 -
Attachment is obsolete: true
|
||
Comment 18•20 years ago
|
||
*** Bug 255959 has been marked as a duplicate of this bug. ***
|
||
Comment 19•20 years ago
|
||
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
|
|
||
Comment 20•20 years ago
|
||
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
|
||
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•