Closed Bug 126224 Opened 23 years ago Closed 21 years ago

(NY Times) Web sites can create pop-up windows using img onload even if unrequested window is blocked (nytimes, image, popup)

Categories

(SeaMonkey :: UI Design, defect)

Product:
SeaMonkey
Component:
UI Design
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WORKSFORME
Milestone:
Future

People

(Reporter: mozilla.org, Assigned: shliang)

References

(
URL
)

Details

(Keywords: relnote, testcase)

Attachments

(2 files, 2 obsolete files)

testcase
1.57 KB, text/html
Details
updated patch
4.51 KB, patch
security-bugs
: review+
jst
: superreview+
Details | Diff | Splinter Review
Under Preferences->Advanced->Scripts and Windows, I have the following three unchecked: "Open unrequested windows", "Move or resize existing windows", and "Raise or lower windows". This effectively eliminates pop-up windows (although it would be nice if I could control this feature on a per-site basis, but that's another story). Somehow, NYTIMES.COM has managed to get around this. It dosn't always happen, but when I visit the site, or click on a link to read a story, low-and-behold, a pop-up window appears with an ad!
Browser, not engine. Reassigning to Preferences and cc'ing Mitch, rginda. Compare similar-sounding bug 123647, "Popup window appears even when "open unrequested windows" is unchecked" although that is at a different site -
Assignee: rogerl → sgehani
Component: JavaScript Engine → Preferences
QA Contact: pschwartau → sairuh
I see this on linux too
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All
Hardware: PC → All
CC'ing Doron.
Keywords: helpwanted
Target Milestone: --- → Future
Did anyone capture the offending script? 123647 was caused by an onLoad in an image tag; we don't check for that. Is this the same thing? BTW, I'll take this bug, unless someone wants to fix it right away.
Assignee: sgehani → mstoltz
QA Contact: sairuh → bsharma
*** Bug 127555 has been marked as a duplicate of this bug. ***
I captured the script at: http://rc3.org/clips/orbitz_popunder_js.txt
this patch lets users set dom.disable_open_click_delay to the max acceptable delay between a mouse click and a window open. dom.disable_open_click_delay is a time in milliseconds.
Attached file testcase —
Attachment #71223 - Attachment is obsolete: true
Mitch, would you like to drive this one into the tree again?
Keywords: helpwanted → mozilla1.0, patch
jst, got time for a sr?
*** Bug 127573 has been marked as a duplicate of this bug. ***
*** Bug 123647 has been marked as a duplicate of this bug. ***
*** Bug 128974 has been marked as a duplicate of this bug. ***
Comment on attachment 71225 [details] [diff] [review] patch without printf and commented out code - Replace all 4 space indentation with 2 space indentation. - s/PRInt64/PRTime/ on the whole diff sr=jst
Attachment #71225 - Flags: superreview+
Comment on attachment 71225 [details] [diff] [review] patch without printf and commented out code r=mstoltz. Good idea! I'll see about getting this into Moz 1.0.
Attachment #71225 - Flags: review+
Comment on attachment 71225 [details] [diff] [review] patch without printf and commented out code a=asa (on behalf of drivers) for checkin to the 1.0 trunk
Attachment #71225 - Flags: approval+
Actually, it occurs to me now that PR_IntervalNow has no units. We should probably use PR_Now instead, and divide |delta| by 1000 to get to milliseconds. Mitch, do you want to own the patch from here, or should I work up a new version?
Attached patch updated patch — — Splinter Review
spacing fixed, initialization fixed to use LL_ZERO instead of literal 0, PR_IntervalNow changed to PR_Now, PRInt64 changed to PRTime (the rest of the file uses PRInt64, btw.)
Attachment #71225 - Attachment is obsolete: true
jst, if you'll give the latest patch your blessing, I'll check it in when the tree opens.
Comment on attachment 73206 [details] [diff] [review] updated patch sr=jst
Attachment #73206 - Flags: superreview+
Comment on attachment 73206 [details] [diff] [review] updated patch Thanks for taking the initiative here, Rob. You know this stuff better than me. r=mstoltz. I'm assuming it's safe to use a PRTime as the seocnd parameter to LL_L2I on all platforms - is that safe? Is PRTime always a long long?
Attachment #73206 - Flags: review+
PRTime is typedef'ed to PRInt64, so on most platforms that would be a long long, and yes, it should always be safe to use with the LL* macros.
Checked in to trunk.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
On pages with a lot of images (news.bbc has over 40, for example), for a modem user, a solution based on time could be troublesome. It would need delicate fine-tuning, and still could be off. There's no easy way to do the clean solution and disable onload=window.open in any element? Also, the patch doesn't seem to add the new pref automatically when you disable "open unrequested windows" in scripts & windows... should it?
Asa gave me a verbal a= to check in to the 0.9.9 branch, so I just checked in there too. Jeremy: I don't think this will be a problem for slow loading pages. The time we measure is between the mouse click and the window.open request. Even on slow pages that time should be very small. As far as the UI goes, someone else will have to knock one together, please file a seperate bug.
Under "What's New In This Release", we should add something like... <li> It is now possible to disable the JavaScript <tt>window.open()</tt> method when it is not called as a result of a mouse click. When the <tt>dom.disable_open_click_delay</tt> pref is set to a nonzero number, window.open will fail when called more than that number of milliseconds after a mouse click. Setting this pref (instructions <a href="http://www.mozilla.org/releases/mozilla0.9.9/#setprefs">here</a>) should turn off pop-up and pop-under ads that use the <tt>onload</tt> handler of <tt>&lt;img&gt;</tt> tags to work around our <a href="http://bugzilla.mozilla.org/show_bug.cgi?id=92955">previous</a> <tt>window.open()</tt> filter. (<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=126224">Bug 92955</a>)<br> <br> <tt>user_pref("dom.disable_open_click_delay", 1000);</tt>
Keywords: relnote
Why is this implemented as a seperate preference from the "Allow scripts to open unrequested windows" pref already implemented? In my mind, that checkbox should turn this feature on and off as well. From a user perspective, they do exactly the same thing -- stop popups. So, while it may be implemented as such, this bug doesn't introduce new functionality for the user. It corrects a bug with the existing functionality. And I strongly believe that there should not need to be a seperate UI pref for this as suggested in Comment #26. That's going to be very confusing for users.
This is new functionality, it does *not* correct a bug in the previous implementation. The previous implementation which "prevents window.open from working during onload, onunload, and timeouts" still exists and has *no* bugs. The fact that our prefs UI mis-represents, or glosses over the details is of no concern to me. File a new bug to bring the UI in line with this new functionality. I don't own that UI and have no personal interest in doing that work myself. UI discussion does not belong on this bug. I'm sure if y'all stop whining here and just file a new bug for the UI, someone will step up and do the work.
*** Bug 120413 has been marked as a duplicate of this bug. ***
I agree with Robert. If the wording of the Pref is "Allow scripts to open unrequested windows," and having this checked does not prevent some sites from opening an unrequested window - as here - then it's a bug. You can look at this two ways. It's a bug with the UI or it's a bug with the Mozilla code not implicitly linking this current bug into the existing UI. Which is less confusing? I would think it would be less confusing to keep the existing UI and link this bug into it so that there's no need for a separate Pref...
Your average web surfer is dumb to the ways of the web developer. They don't know the difference between a window.open() in a body onload, an image onload, one that's just sitting out there to be executed sans event. To them there is no difference. The behavior of these, however, is the same and its this bahavior that they want to disable. If you support the opposite view then every time a sneaky developer finds a way of opening an unrequested popup then you'd have to add a new option in the UI. Can you imagine: - Disable Unrequested Popups from body.onload - Disable Unrequested Popups from image.onload - Disable Unrequested Popups from iframes - Disable Unrequested Popups from js/DOM inserted script elements - Disable Unrequested Popups from onmouseover - Disable Unrequested Popups from onmouseout I suggest that any developer action that causes the behavior of an "unrequested popup" be grouped under this singular preference. Call this whining if you'd like, but I think this bug needs to be reopened and dealt with.
I've filed bug 132031 to deal with the UI. Maybe one of you wants to submit a patch, or something.
*** Bug 133871 has been marked as a duplicate of this bug. ***
*** Bug 139318 has been marked as a duplicate of this bug. ***
I can't get this workaround to work on RC1 and nytimes.com I've tried setting the value to 1000,250,100,10, and 1. I would assume faster machines would use shorter times.
Bug 126224 fixes just one method of opening unrequested popups. It's easy to implement others. For example, I can open popup from document.body.onmousemove handler. Event triggers when user just moves the mouse in the window. It means in 99.99% - popup will come up. I think it should be reopened with more general summary.
*** Bug 144481 has been marked as a duplicate of this bug. ***
*** Bug 145628 has been marked as a duplicate of this bug. ***
*** Bug 146480 has been marked as a duplicate of this bug. ***
*** Bug 147184 has been marked as a duplicate of this bug. ***
*** Bug 153362 has been marked as a duplicate of this bug. ***
*** Bug 153778 has been marked as a duplicate of this bug. ***
Summary: NY Times web sites creates pop-up windows even if that feature is disabled → NY Times web sites creates pop-up windows even if that feature is disabled (using img onload)
*** Bug 154270 has been marked as a duplicate of this bug. ***
*** Bug 154476 has been marked as a duplicate of this bug. ***
*** Bug 155134 has been marked as a duplicate of this bug. ***
*** Bug 155545 has been marked as a duplicate of this bug. ***
*** Bug 155901 has been marked as a duplicate of this bug. ***
*** Bug 146570 has been marked as a duplicate of this bug. ***
*** Bug 154988 has been marked as a duplicate of this bug. ***
*** Bug 156673 has been marked as a duplicate of this bug. ***
*** Bug 157980 has been marked as a duplicate of this bug. ***
Why was this implemented as a timeout? It seems to me that, no matter *how* much time has passed, if the window-creation action is not occurring as a direct result of a mouse click, then no windows should be created. In other words, windows should be creatable by *inclusion*: when and only when: - I've selected "File / New / Navigator" - I've clicked the middle button on a HREF - I've selected "Open in New Window" from the context menu - we're inside the scope of an onClick handler of an HREF that was loaded as the direct result of a mouse click. Relying on timeouts suggests that you've lost track of how you got where you are, and that's the actual bug that should be fixed. Right?
Alias: nytimes
*** Bug 153798 has been marked as a duplicate of this bug. ***
*** Bug 158462 has been marked as a duplicate of this bug. ***
*** Bug 158536 has been marked as a duplicate of this bug. ***
*** Bug 127757 has been marked as a duplicate of this bug. ***
*** Bug 126905 has been marked as a duplicate of this bug. ***
We keep getting bugs describing the case every day. I don't see how come we have this RESOLVED FIXED. Maybe WONTFIX, but not FIXED! I'll keep an eye on the user input for the next week, and will reopen next Sunday. If anybody objects, please reply.
I don't see any point in waiting another week (with all due respect). I count 27 dups.....with most of them happening after this was "fixed". So, I'm reopening this now as the existing UI pref should take care of this problem.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
I think JWZ is right in comment #53 we should not keep developing workarounds for the ways web developers bombard us with pop-ups. Stopping them alltogehter unless called from the interface or from a direct onclick handler (or the call to a function as the target of a href) is the only way to ensure that we don't have to come back to the drawing board every time. If we have a pref that disables unrequested windows, lets go all the way and disable unrequested windows... It should be much easier to create an inclusive list of "requested" windows than create a list of all the possible ways something could be unrequested.
Keywords: mozilla1.0 → mozilla1.1
At risk of being one of those dorks who writes "me too" posts, I also concur with JWZ's comment 53.
I concur with Mike Young's comments above. I opened one of the "dupe" bug reports regarding this issue and I think Mike Young's comments really "hit the nail on the head". Peace.... Tom
This bug was marked fixed because it seemed like all we needed was the UI for the new timeout-based pref. Looking back on it, I don't think we should hook this up to the UI at all. I don't like the false-positive debugger users will run into when stepping over a window.open call. Bug 132031 should probably be closed WONTFIX. A timeout-based solution was chosen because it was easy to implement. The first patch took me all of about 30 minutes to hack together. It's not my job to stop pop-ups. I just saw what I thought would be an easy work-around, and did it. I encourage any of you to Just Do It. I'll be happy to review your work. The main pref (the one that is actually hooked up to the UI) was introduced in bug 92955. The first patch there actually looked at the xpconnect stack to deny anything that came from "onload" or "onunload". One could use something similar to *allow* only "onclick"s. I'm not sure how you'd find out if you were in a javascript: url, but it's probably possible. If you were to try something like that, you'd probably do it in CheckForAbusePoint, which is here: <http://lxr.mozilla.org/mozilla/source/dom/src/base/nsGlobalWindow.cpp#2816>.
*** Bug 158705 has been marked as a duplicate of this bug. ***
Robert Ginda: re your comment 64, are you saying that a patch to prevent window openings shouldn't be attached to the "Open Unrequested Windows" checkbox?
There are two prefs here. The first was introduced in bug 92955, and is "dom.disable_open_during_load". This pref blocks window.open() calls that are made from script that runs outside of any function, from an onload or onunload event, or from a setTimeout/setInterval. This pref is what is currently hooked up to "Open unrequested windows". I think it's just dandy, and it does the job fine for me. Then the ny times came along and put a window.open in an <IMG> onload handler. Maybe they did it to get around "dom.disable_open_during_load", or maybe it was dumb luck. As a quick hack, I came up with a SECOND pref, "dom.disable_open_click_delay", which blocks window.open calls based on how soon they happen after a mouse click. This pref was never added to the UI, instead bug 132031 was filed with the hopes that someone else would do it. In comment 64, I suggested we SHOULDN'T add this pref to the UI, because "dom.disable_open_click_delay" probably isn't the right idea, and it is prone to false positives. Instead, I say "dom.disable_open_click_delay" should probably be backed out. Looking back at nsGlobalWindow.cpp now, I think we can once again scrap the idea of looking at the xpconnect stack, and instead set a mInClickEvent flag in GlobalWindowImpl::HandleDOMEvent. This flag would only be true for the life of the HandleDOMEvent call, when aEvent->messsage was NS_MOUSE_RIGHT_CLICK (and whatever else makes sense.) We would still need to work out javascript: urls, unless they are dispatched from the NS_MOUSE_RIGHT_CLICK event (which would things very easy.)
rginda, would you want to back out the patch here and create a new bug to "Strengthen Disable Open Unrequested Windows"? marking this bug as dup? I think your proposed idea seems about right, but I think we should be able to determine the source of the call to the function without resorting to flags for onClick. (although I might be wrong...) From what I see, there are only the following _valid_ requested windows (I am open to additions...): 1. Opened from the interface (in new window, middle click, File > New, Accel-N, etc.) -- I believe that these are already immune and don't need to be worried about. 2. Opened via an onClick, onDblClick, onMouseDown, onMouseUp, onKeyPress, onKeyDown, onKeyUp, onSubmit?(debatable). 3. Opened via a javascript: URL of a clicked link. The onSubmit is not necessarily a user-activated event, but is often used as such. (I would say onFocus too, but the idea of someone *requesting* a popup window via tabbing into a field seems far-fetched.) The problem is that a malicious web developer could call a submit() routine on a form with no visible elements and no href and effectively get around the popup blocking.
I agree that a new bug is needed at this point so as to avoid confusion. (Neither this bug nor bug 132031 really cover what we want, which is "Strengthen Disable Open Unrequested Windows" as just suggested.)
> rginda, would you want to back out the patch here and create a new bug to > "Strengthen Disable Open Unrequested Windows"? marking this bug as dup? Maybe. Maybe this bug should stay open so folks can find it, and "Strengthen Disable Open Unrequested Windows" should be marked as blocking this bug. > I think your proposed idea seems about right, but I think we should be able to > determine the source of the call to the function without resorting to flags for > onClick. (although I might be wrong...) I'm not sure how you're going to know that window.open was called from an onclick event without maintaining some sort of state to that effect. Unless you resort to the xpconnect stack checking code. > 1. Opened from the interface (in new window, middle click, File > New, > Accel-N, > etc.) -- I believe that these are already immune and don't need to be worried > about. Correct, windows opened from chrome code are always allowed, that's what the |if (item)| condition in GlobalWindowImpl::CheckForAbusePoint is doing. > 2. Opened via an onClick, onDblClick, onMouseDown, onMouseUp, onKeyPress, > onKeyDown, onKeyUp, onSubmit?(debatable). > 3. Opened via a javascript: URL of a clicked link. what about |document.location = "javascript:void window.open('foo.html');";|? I think this whitelist idea has more nooks and crannies than people suspect. If you open "Strengthen Disable Open Unrequested Windows", don't assign it to me (cc: is ok.) I'll help out where I can, but I don't have the kind of free time I think it will take to get this right.
I have filed bug 159036 to deal with the issue of Strengthening Disable Open unrequested windows. I have added only rginda to the CC list (because i usually hate it when people CC me without permisssion, so if you are on this list you have to add yourself) I have answered rgindas comment about document.location = javascript: there And if that bug is fixed, it will in turn fix this bug... The issue still exists about backing out the patch in this bug.
Depends on: 159036
*** Bug 159385 has been marked as a duplicate of this bug. ***
*** Bug 160527 has been marked as a duplicate of this bug. ***
*** Bug 153825 has been marked as a duplicate of this bug. ***
*** Bug 160652 has been marked as a duplicate of this bug. ***
Filed bug 160670, "back out dom.disable_open_click_delay".
*** Bug 161366 has been marked as a duplicate of this bug. ***
*** Bug 157629 has been marked as a duplicate of this bug. ***
Should we mark this dupe of bug 159036 (strengthen via whitelist)?
I would advocate leaving it open for discoverability (searching on NY times). Just look at the names or the URLs in the Dupes.
Hopefully bug 159036 will be the chosen solution to fix this bug, but it is still a different bug. There is always the possibility that the developers would like to fix this bug by simply blocking IFRAMES. Leave this bug open, but if you have some free time to write code, try your hand at 159036 before you work here... :-)
Another workaround (besides disabling iframes) is to completely turn off window.open for nytimes.com. Something like this... user_pref("capability.policy.popupsites.sites", "www.nytimes.com"); user_pref("capability.policy.popupsites.Window.open", "noAccess");
>>Another workaround (besides disabling iframes) is to completely turn off >>window.open for nytimes.com. Something like this... >>user_pref("capability.policy.popupsites.sites", "www.nytimes.com"); >>user_pref("capability.policy.popupsites.Window.open", "noAccess"); Would the user then have to configure EACH and every address to block? I reported this same problem but on a DIFFERENT website and that bug was marked as a dupe of this one. Peace.....
You can add more sites to the "popupsites" zone by listing them in the .sites pref, like... user_pref("capability.policy.popupsites.sites", "www.nytimes.com www.someothersite.com www.yasite.com");
*** Bug 163037 has been marked as a duplicate of this bug. ***
>>You can add more sites to the "popupsites" zone by listing them in the .sites >>pref, like... >>user_pref("capability.policy.popupsites.sites", "www.nytimes.com >>www.someothersite.com www.yasite.com"); Ok, will there be an interface element to this ".sites" pref file through the browser or is this something the end user will have to modify manually? I think a browser interface element would minimize bug reports as people "discover" (after filing the bug report) that they must edit the ".sites" file. Peace.....
Blocks: majorbugs
Add Yahoo to the mix. I just visited http://news.yahoo.com/ with 2002082109 trunk and up came the plague of the Internet (an X2 spycam popup).
Will all due respects to Jerry Baker's comment 87, the X cam is not the *plague* of the internet, but the plaque of the internet, i.e., what you get for not brushing and flossing your web browser's source code. Vote for bug 126224 today!
sorry if I am wrong, I can't find any code in nsGlobalWindow.cpp CheckForAbusePoint() that blocks onunload pop-ups.
Summary: NY Times web sites creates pop-up windows even if that feature is disabled (using img onload) → (NY Times) Web sites can create pop-up windows using img onload even if unrequested window is blocked
sorry if I am wrong, I can't find any code in nsGlobalWindow.cpp CheckForAbusePoint() that blocks onunload pop-ups.
*** Bug 161975 has been marked as a duplicate of this bug. ***
Daniel, you are wrong. Look at the code that sets mIsDocumentLoaded.
Robert, yes, thank you. seamonkey/source/dom/src/base/nsGlobalWindow.h line 294 PRPackedBool mIsDocumentLoaded; // true between onload and onunload events
Blocks: popups
The workaround described in comment 82 with setting capability.policy.popupsites does not work for me (build Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0.0) Gecko/20020529). I added the two lines to prefs.js, but the NYTimes popup still appears. Has this been added in a later build than what I have installed?
In response to comment 94: since 0.9.9 you also need to add this line: user_pref("capability.policy.policynames", "popupsites"); see: http://www.mozilla.org/projects/security/components/ConfigPolicy.html An easier fix against all popups like these is of course setting this preference: user_pref("dom.disable_open_click_delay", 1000); *winces as he spams another load of people*
*** Bug 178082 has been marked as a duplicate of this bug. ***
*** Bug 178644 has been marked as a duplicate of this bug. ***
Summary: (NY Times) Web sites can create pop-up windows using img onload even if unrequested window is blocked → (NY Times) Web sites can create pop-up windows using img onload even if unrequested window is blocked (nytimes, image, popup)
*** Bug 179088 has been marked as a duplicate of this bug. ***
*** Bug 181109 has been marked as a duplicate of this bug. ***
Don't know if this helps, but at least in w/ 1.2.1 the uninvited pop-ups happen only going BACKWARD in the browser, from an article back to, say, the home page, at least for me. OTOH, the slick Tabs function (thankyouthankyouthankyou) has sort of relegated the Back button to, er, the dustbin of history. Quiz: who said that?? BTW, I'm not a programmer, just a simple WAN analyst....one who really appreciates Mozilla, I introduce all my (L)users to it.... NYTimes opening pop-ups is simply annoying, an in-your-face by heartless adverti$ing wonks....and the ads! So cheesy... Cheers!
I swear this didn't happen in 1.3a, but it is certainly present in 1.3b. Any luck with a fix? What's up with the new "popup windows" preferences anyhow?
*** Bug 195653 has been marked as a duplicate of this bug. ***
*** Bug 195466 has been marked as a duplicate of this bug. ***
*** Bug 186850 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.1
*** Bug 200107 has been marked as a duplicate of this bug. ***
FYI, I am using 1.3 stable Mozilla, and every now and again NYT squeaks one by the pop-up filter. Since I do tabbed browsing, and almost never hit the 'back' button, this happens only when accessing www.nytimes.com front page. From there I think I have had like 1 pop-up *ever* accessing a page further in, and I read nytimes several times daily. I wonder-do they have some guy out there that does nothing but try and defeat Mozilla's pop-up filter? Weird. Eric
Mozilla's popup blocking also fails to block a popup on Consumer Reports' webpage (http://www.consumerreports.org/main/home.jsp). This popup window appears to be initiated by mouse-over events on the navigation bar at the top of the page. These appear to be the relevant sections of code: <script language="JavaScript"> <!-- function showWindow(e) { var x=y=0; if (e != '') { x = e.screenX; y = e.screenY; } myWindow=window.open('http://cdn.consumerreports.org/static/popup/didyouknow.html','windowName', 'width=200,height=300,screenX=' + x + ',screenY=' + y + ',left=' + x + ',top=' + y); } //--> </script> <tr><td><div align="center" class="blackbold_16-px"><a href="#" onClick="if (window.event || document.layers) showWindow(window.event); else showWindow('');" onMouseOver="if (window.event || document.layers) showWindow(window.event); else showWindow('');"><img SRC="http://cdn.consumerreports.org/static/popup/didyouknow.gif" alt="Did you know?" width="109" height="39" border="0"></a></div></td></tr>
*** Bug 202494 has been marked as a duplicate of this bug. ***
*** Bug 202745 has been marked as a duplicate of this bug. ***
*** Bug 204768 has been marked as a duplicate of this bug. ***
Another site can evade Firebird's popup blocker. From http://www.geocities.com/rosannaarquette2/ select http://www.geocities.com/rosannaarquette2/pictures.html. You will be presented with a series of popup windows from http://www.popupad.net. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030516 Mozilla Firebird/0.6, popup blocking and javascript both enabled. When javascript is disabled, the popup windows are not launched.
It happens in mozilla as well. It's a form submission, so it almost doesn't fit in this bug. Here's the code that does it: <script language=JavaScript> <!--// function loadpopup() { document.flauncher.submit(); focus(); setTimeout('focus()',2000); } // --> </script> </head> <body BGCOLOR="#E4ECF6" onLoad='loadpopup()'> <form name='flauncher' action='http://www.popupad.net/ats/switch.php' target='adv' method='post' onSubmit='focus();'>
Samuel (and possible Ed Hume): yours are different from this bug report since this one is about opened popups created by img onload event - yours are created using onload form.submit. This is currently discussed in bug #144726 so you may also want to add yourself to the CC-list there.
Comment #112 confuses me a bit (so what's new). Is it the "onLoad" in the "body" tag, or the "action" in the "form" tag that is causing this particular popup? In any case, the original report in Bug #144726 has the same source as Comment #112. In other words, don't post an answer to my question to this bug, just send private eMail or post to Bug #144726.
Moving Popup Blocking bugs to XPApps, assigning to shliang
Assignee: mstoltz → shliang
Status: REOPENED → NEW
Component: Preferences → XP Apps
*** Bug 209386 has been marked as a duplicate of this bug. ***
I have yet to get an unrequested popup from NYTimes and I visit it daily Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5b) Gecko/20030911 Firebird/0.6.1+
The NYTimes may have stopped annoying its customers but the technique described in this bug still needs to be addressed.
I agree with the comments that when user says "block unrequested popups" that's what they mean, no matter how they're created. I just ran across an annoying popup ad (though interesting in that it's borderless) on the Channel 4 (british tv) website: http://www.channel4.com/entertainment/tv/microsites/G/graham/weblogs/index.html This appears to be the offending section, but I've never heard of an iframe tag before: <script language="JavaScript"><!-- if (!document.c4Category) document.c4Category = ""; if (!document.c4Module) document.c4Module = ""; banStr = "category="+document.c4Category+"&module="+document.c4Module+"&content="+document.c4Content+"&size=468_60&"; var now = new Date(); RND = now.getSeconds(); document.write ('<iframe width="468" height="60" marginwidth="0" marginheight="0" hspace="0" vspace="0" frameborder="0" scrolling="no" bordercolor="000000" src="http://ads.channel4.com/html.ng/site=C4&'+ banStr +'Rnd='+ RND + '">'); document.write ('<scr'+'ipt language="JavaScr'+'ipt" src="http://ads.channel4.com/js.ng/params.richmedia=yes&site=C4&'+banStr+'Rnd='+ RND + '"></scr'+'ipt>'); document.write ('</iframe>');//--></script>
iframe was, I think, created by Microsoft but is now supported by most browsers. What I've never heard of is scrolling=no, which is what would appear to make it "popup-like" in that it's positioned during redering, and then never moved as a result of scrolling. Personal opinion here: "scrolling=no" should not be obeyed if popups are disabled. There's just no good reason for it....
The testcase WFM (I don't get any pop-ups) in Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040131 Firebird/0.8.0+ (aebrahim) (That build is before danm's checkin for bug 197919.)
All testcases WFM Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040209. Michaell confirmed WFM on IRC.
Status: NEW → RESOLVED
Closed: 23 years ago → 21 years ago
Resolution: --- → WORKSFORME
Blocks: pop-up-arms-race
No longer blocks: popups
Product: Core → Mozilla Application Suite
No longer blocks: majorbugs
Status: RESOLVED → VERIFIED
Keywords: testcase
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: