Closed
Bug 240151
Opened 20 years ago
Closed 20 years ago
Popup blocker fails by javascript window.location.href & window.open
Categories
(Firefox :: General, defect)
Tracking
()
RESOLVED
INVALID
People
(Reporter: funonline, Assigned: bugzilla)
Details
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040206 Firefox/0.8 The popupblocker fails when a javascript is called with this parameters : <script language="JavaScript"> function xyz() { window.location.href="http://testfirefox.com/site123456789/"; window.open("http://www.somewhere-in-the-net.com","Window2"); } //--> </script> After this you lay the script on a image with a new link: <a href="javascript:xyz()"><img src="http://testfirefox.com/site123456789/test1.gif" width="300" height="100" border="0"></a> Now you click on the link (image) the href page loads, but also a new popupwindow :( Reproducible: Always Steps to Reproduce: 1. Make a clean htmlfile with the code above 2. Replace the used links with real one´s 3. Save and open the htmlfile and click ... ;) Actual Results: A popup window appears Expected Results: No popup ;) ROFL FF 0.8
Comment 1•20 years ago
|
||
Another case of javascript shenanigans, this one devised by a leading online advertising service: This script allows a page to change the location of the original window that called it, making the original window a kind of sneaky pop-under: <script language="javascript"> <!-- if (typeof(opener) == "object" ) opener.location="http://www.mozilla.org"; // --> </script> Steps to reproduce: 1. Create a clean HTML file and include the above code in it. 2. Create another HTML file with a _blank link to the file created in Step 1. 3. Save both files, open the file created in Step 2 and click. Actual results: The file with the javascript code opens in a new window, then the original window's location changes to that referenced in the script above. Expected results: Would like to see the original calling window left alone by default. :( I reproduced this issue with Firefox 0.8 on Windows ME.
Summary: Popup blocker fails by javascript window.location.href & window.open → Popup blocker fails by javascript window.location.href & window.open
Comment 2•20 years ago
|
||
er, if you click on a link that includes window.open() then the popup is a result of your mouseclick. Are you expecting ALL uses of window.open() to be suppressed, or just ones that follow arbitrary other lines of code? comment 1 is legitimate usage of javascript. We would break any number of legitimate uses that rely on this working.
QA Contact: mconnor
Mike and I collided. Appending my comment anyway, which agrees with his: But this isn't a popup window. It's simply a link which opens a window. It might as well be <a href="javascript:window.open()"> which is never blocked by the popup blocker. And yes, in your example the script goes on to do other things. In this case, changing the current location of the window. This does make the situation look confusingly like a popup window being opened during page load time but in fact it's still just a window being opened in direct response to a link being clicked. Mozilla behaves correctly in opening that window. It turns out that the window's location change is running asynchronously while the new window is being opened. What would be a bug is: if the window open can be delayed long enough to allow the location change to begin loading, so that the window open would then be interpreted as a popup and be blocked. I don't think that's possible (knock on wood) but that, that *would* be a bug. Closing invalid.
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → INVALID
Comment 4•20 years ago
|
||
Well, I'm a little stymied about what to do at this point. The resulting window of the code I presented in Comment 1 is technically not a pop-up (or a pop-under), yet to the millions of average users it still would be considered a pop-up, no matter what strategy was used. No target page should be allowed to refer back to the calling window and change its location without consent of the user, especially when the tactic causes the calling window's original location to disappear from the Back history. It's just not acceptable behavior. Currently I can't think of any way to prevent this in Firefox 0.8 without disabling Javascript altogether, which I really don't want to do. If there's currently no entry that addresses this particular issue, I'll create one as a suggestion for improvement, if I can't technically call it a bug of the pop-up blocker.
Comments 1 and 4 don't have much to do with this bug. Granted it's a related issue, in the same way that the Indian Bluechat and the Rufous Breasted Bush Robin are members of the same family. If you'd like this problem to get mindshare, it really wants to be in its own bug. But I'm a softie on Tuesdays. Mindshare follows: I expect such a bug would also be quickly closed. It's a long-standing policy that windows from related domains are allowed to mess with each other. It is rather a shame that the opener's history isn't updated. That'd be bug 178729. In the realm of personal fixes, less intrusive than disabling JavaScript would be adding these preferences (note the capital W in "Window"): user_pref("capability.policy.policynames", "openerAbuse"); user_pref("capability.policy.openerAbuse.sites", "http://advertising.evil"); user_pref("capability.policy.openerAbuse.Window.location", "noAccess"); See http://www.mozilla.org/projects/security/components/ConfigPolicy.html
You need to log in
before you can comment on or make changes to this bug.
Description
•