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)

x86
Windows XP
defect
Not set
normal

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
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
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
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.