Closed Bug 136195 Opened 23 years ago Closed 10 years ago

Open Unrequested Windows pref blocks window.open() after setTimeout

Categories

(Core :: Security, defect)

x86
Windows 98
defect
Not set
major

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: horkana, Assigned: dveditz)

References

(Blocks 1 open bug, )

Details

Attachments

(3 files)

Works in Netscape 4.79 http://www.spiderman.sonypictures.com/index2.php Click on the image with the text "launch US site" (mumble mumble not the only people who speak english ya know ...) In the status bar there is the message: javascript:loadPage(''); Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.9+) Gecko/20020408
Browser, not engine. Reassigning to Plug-ins until we can get further information. This is working perfectly for me with Mozilla trunk build 20020406xx on WinNT. When I mouseover the "LAUNCH THE U.S. SITE" link, I do see javascript:loadPage('') in the status bar, but when I click on the link, this works fine. A new child window comes up, which plays a Flash plug-in. The plug-in plays successfully, and I get no errors in the JavaScript Console. Everything is just the same as it is in NN4.7 for me. Alan: 1. What happens when you click on the "LAUNCH THE U.S. SITE" link? 2. Does the child window come up? 3. Do you see any errors in Tools > Web Development > JavaScript Console? 4. Does the child window come up, but the Flash plug-in doesn't play? 5. What version of Shockwave Flash do you see when you do Help > About Plug-ins? I have this: C:\Program Files\Netscape\Communicator\Program\Plugins\NPSWF32.dll Shockwave Flash 5.0 r41
Assignee: rogerl → beppe
Component: JavaScript Engine → Plug-ins
QA Contact: pschwartau → shrir
When i click on the link nothing happens. i dont really understand the Javascript debugging information There is an error "popup has no properties" on line 110 which seems like it might be relevant. I dont know if it is relevant but In preferences, Advanced, Scripts and windows i have unticked "Open Unrequested Windows".
> I dont know if it is relevant but In preferences, Advanced, Scripts and > Windows I have unticked "Open Unrequested Windows". Yes, this is relevant! Could you check that box, then close and restart Mozilla? Then see if the link works. If it doesn't, could you open the JavaScript Console and copy the error you see there directly into this bug? Thx -
"Open Unrequested Windows" it works now, when that box is ticked bumping severity up, if websites start pulling crap like that then "Open Unrequested Windows" will be useless. Im not sure if plugins is the right component, Evangelism maybe?
Severity: normal → major
Alan: thanks; reassigning to Browser-General component.
Assignee: beppe → Matti
Component: Plug-ins → Browser-General
QA Contact: shrir → imajes-qa
Here is the link in question: <a href="javascript:loadPage('');" onMouseOver="imgOn('us');" onMouseOut="imgOff('us');"> From view-source:http://www.spiderman.sonypictures.com/js/openMain.js: function loadPage(link) { glink = link; flashDetection(); setTimeout("openMain(1)", 125); } where we have function openMain(full) { var IE = (navigator.appName == "Microsoft Internet Explorer"); if (full) { if (flashmode == 1){ w = 800; h = 570; leftPosition = (screen.width) ? (screen.width-w)/2 : 0; topPosition = (screen.height) ? (screen.height-h)/2 : 0; var windowprops = 'width=' + w + ',height=' + h + ',top='+ topPosition +',left='+ leftPosition+ ',toolbar=no,location=no,directories=no,status=no,scrollbars=no,menubar=no'; MainWin = window.open('/main.php?link='+glink,'spideymain',windowprops); } if (flashmode == 1){ // top.document.location.href = "/alerts/thankyou.html"; }else{ top.document.location.href = "/alerts/flash.html"; } } }
Testcase #1 is just this: <a href="javascript:openNewWindow();">Click here to open a new window</a> <script> function openNewWindow() { MainWin = window.open('http://www.mozilla.org'); } </script> Testcase #2 is the same thing, but called from setTimeout(---, 125): <a href="javascript:delayOpenNewWindow();">Click here to open a new window</a> <script> function delayOpenNewWindow() { setTimeout('openNewWindow()', 125); } function openNewWindow() { MainWin = window.open('http://www.mozilla.org'); } </script>
Reassigning to Security:General; cc'ing rginda. When you unclick Preferences > Advanced > Scripts&Windows> Open Unrequested Windows then testcase #1 still functions properly. You click on the link, you get the new window. However, testcase #2 now fails. You click on the link, and nothing happens. ONCE, I saw this error in the JavaScript Console: Error: uncaught exception: Permission denied to call method Window.setTimeout I can't remember if that happened with a prototype of testcase #2 that I have since changed, or not; sorry. I only saw it once. So there are two questions here: 1. Was it our intent that unchecking "Open Unrequested Windows" would block window.open() if it is wrapped in setTimeout()? That doesn't make sense to me: it's still under a link that the user has deliberately clicked; what difference should it make if a setTimeout() delays the window.open() a little bit? 2. If the answer to 1. is "Yes", should we be seeing an error in the JS Console in this case? I got one once, as reported above, but then never again -
Assignee: Matti → mstoltz
Status: UNCONFIRMED → NEW
Component: Browser-General → Security: General
Ever confirmed: true
QA Contact: imajes-qa → bsharma
Summary: spider man website javascript problem → Open Unrequested Windows pref blocks innocent window.open()
If we don't block window.open() in timeouts, it becomes very easy for popup-ad spammers to bypass our blocking, by wrapping their calls in timeouts. I doubt there are too many cases of a legitimate open call being put in a timeout - or are there? If this is really a problem, we'll have to think of an even more detailed rule (block window.open in only those timeouts initiated by onLoad, etc.) As for 2) I don't think the popup-blocker in nsGlobalWindow.cpp does any console reporting - do you think it should?
Status: NEW → ASSIGNED
Hmm, so how does the rules currently differintiate between window.open from a click, and window open by itself. Does having a timeout in someway lead to you not being able to detect that a click was the ultimate cause?
We currently detect a window.open that 1) Comes from inside a timeout or 2) Comes before the page has finished loading and block them. Note that check #2 is useless if check #1 is not done...
Summary: Open Unrequested Windows pref blocks innocent window.open() → Open Unrequested Windows pref blocks window.open() after setTimeout
*** Bug 143979 has been marked as a duplicate of this bug. ***
OK this is now also happening from many of the games at www.newgrounds.com except there does not appear to be a timer on them. But having don't open unrequested windows, cause the game/movie not to be able to launch. Strangly enough this doesn't happen every time. Sometime they window will open, sometimes it won't.
*** Bug 149969 has been marked as a duplicate of this bug. ***
Regarding comment #11 and how often an open call is inside a timeout. I refer you to the following code from Bug #149969, which itself is from http://www.hermitagemuseum.org/fcgi-bin/db2www/browse.mac/typeIndex?selLang=English&selCateg=picture // Open the window (the timeout is needed to work around IE3 timing bugs) setTimeout("w = window.open('" + page + "', '" + winName + "', 'width=300,height=400')", wait);
Um. I can also verify that this occurs at line 214 of https://members.ud.com/services/home.htm - this requires a login, unfortunately, but the line is: <a href="javascript:openWindow('/services/_pw_points_def.htm', 450, 460, true)">Points</a> openWindow is in /js/browser_window_functions.js, and looks like this: function openWindow(strURL, pixW, pixH, blnSB) { var strSB = "no" strLocation = strURL; strWHandle = "UDWIN"; if (blnSB) {strSB = "yes"}; strProps = "resizable=yes,scrollbars=" + strSB + ",toolbar=no,location=no,directories=no,status=no,menubar=no,width=" + pixW + ",height=" + pixH + ",top=10,left=10"; window.open(strLocation, strWHandle, strProps); } Nope, no onTimeout here...!
One more problem with window.open and 'Open Unrequested Windows': When 'Open Unrequested Windows' is unchecked, bookmarklets which use window.open are blocked. Test Case: The following bookmarklet, for instance (drag it to the bookmark bar, then click on the resulting bookmark) should open a new window even with Open Unrequested Windows unchecked: <a href="javascript:window.open('http://www.google.com/', '_new');">Click Me</a> Nothing happens when OUW is unchecked, but the bookmarklet works perfectly when the box is checked. Mozilla 1.1 release, Windows 2000 SP2.
Bug appears in Moz1.1 in XP too. No JS clicks work for me. Don't remember seeing this in Moz1.0. Strange.
Blocks: popups
*** Bug 182005 has been marked as a duplicate of this bug. ***
One thing to add on comment #19. I had this problem with 1.2 and now it continues with 1.3a. Bookmarklets with window.open do not function with the 'open unrequested windows' option turned off. But only sometimes. I have a bookmarklet that I use quite often to highlight words and it'll pop up a window to dictionary.com. If the bookmarklet doesn't work the first time, I can click it again, sometimes it'll work, otherwise, switch tabs, or highlight some other text and try again, eventually, I can get the bookmarklet to work. It seems random. However, with the pop-up blocking turned off, it works 100% of the time. So it must be related. <a href="javascript:void(open('http://dictionary.reference.com/search?q=' + window.getSelection(),'dictionary','height=640,width=600,scrollbars=yes,resizable'));"> Dictionary </a>
Attached file Real-world ad pop-up using setTimeout (deleted) —
"Open Unrequested Windows" isn't in Mozilla 1.3b. so.... Using the Popup manager, a site like www.waum.com creates a frameset. One of the frames, pop.php, contains: <body OnLoad="window.setTimeout('advertiseMe()', 3000)"> </body> Which creates a popup, even if disabled. (attached source)
Is this bug still valid? It seems like the fix wouldn't be so hard (though I don't know what goes on under the hood): You already have a mechanism for determining whether some executing JS code has permission to open a window (I'm guessing by checking what's at the base of its call stack). Whenever setTimeout() gets called, copy this permission flag into whatever data structure you use to keep track of the timer. When executing JS in response to a timer, check this flag to decide if it can open windows. The only issue I see here is that a single click (etc.) can start a lot of timeouts, so you'd need to ensure you only copy over this permission for the first setTimeout(). That can't be hard---there must already be a similar mechanism to ensure window.open() only succeeds once.
using firefox 1.0.4 on winxpsp2 with popups blocked the testcases in comment 7 and comment 8 both open windows and comment 23's attempt to open a popup from onload is blocked. Works for me?
Assignee: security-bugs → dveditz
Status: ASSIGNED → NEW
QA Contact: bsharma → toolkit
Resolving per Comment 25
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: