Closed Bug 144726 Opened 22 years ago Closed 21 years ago

Can use form.submit() to circumvent popup blocking, window.open() prefs

Categories

(SeaMonkey :: UI Design, defect)

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

Tracking

(Not tracked)

Status:
RESOLVED DUPLICATE of bug 210560
Milestone:
Future

People

(Reporter: jnerin, Assigned: shliang)

References

(
URL
)

Details

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
BuildID:    2002051009

If you open the page http://redvip.homelinux.net/popup.html a new popup is
launched althougth it shouldn't as I have it not allowed in my preferences.



Reproducible: Always
Steps to Reproduce:
1.go to http://redvip.homelinux.net/popup.html
2.wait until it finishes loading
3.see for yourself

Actual Results:  A new popup window is launched

Expected Results:  nothing, I have not allowed to open new windows to the scripts.

The code responsible for this is the next one:

<script LANGUAGE="JavaScript">
self.defaultStatus = "Done";
</SCRIPT>
<script language=JavaScript>
<!--//
function loadpopup()
{
document.flauncher.submit();
focus();
setTimeout('focus()',2000);
}
// -->
</script>

<body  onLoad='loadpopup()'>

<form name='flauncher' action='http://redvip.homelinux.net/popup2.html'
target='adv' method='get' onSubmit='focus();'>
</form>
Confirming.

I experience this too, unless I also uncheck "Open a link in a new window" in
addition to "Open unrequested windows" in Preferences > Advanced > Scripts &
Windows.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Sorry, the link is opening due to the "target" on the form, not because of
anything the JS does.  So in fact "Open a link in a new window" is the pref that
should control it.

The fact that we should have a _single_ checkbox that toggles both prefs is a
separate issue, already filed.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → INVALID
Verified Invalid with Mozilla trunk binary 2002051408 on WinNT. 
Unchecking "Open a link in a new window" pref stops the new window.

This does get confusing, because there are so many variations.
Jorge: you might like to cc yourself on bug 115353,
"Clean up UI and Wording for Scripts and Windows Pref"

The idea there is to make the user interface clearer on these issues.
Status: RESOLVED → VERIFIED
I don't agree that this bug is invalid.

> Sorry, the link is opening due to the "target" on the form, 
> not because of anything the JS does.
The JS submits the form and hence opens the window.

> So in fact "Open a link in a new window" is the pref that
> should control it.
There are no links involved here. The user opens the page. On load a JS function
is called, which opens the window. The fact that it is opened using submit() on
a form with a named target instead of window.open() doesn't make any difference
to the user.

If JS is able to open windows using form.submit() even though "Open unrequested
windows" is unchecked, then this option doesn't make much sense at all, because
it is easily circumvented. The "popup spammer" could just replace all
window.open() calls with form.submit().  He may not be able to specify whether
the window should have toolbars etc., but he /is/ still able to open a window.

> The fact that we should have a _single_ checkbox that toggles 
> both prefs is a separate issue, already filed.
If the two options are merged into one checkbox, this discussion is no longer
relevant. Will this actually happen or is it only being discussed? Could you
provide a bug # ?

I know that unchecking "Open a link in a new window" pref stops the new window,
but then the page changes to the "popup" one, I think the correct way of doing
this is to ignore the form submit like if it was a timed popup.

As it has been said it's easy for a webmaster to change it's popups to be this
way, defeating this javascript preference, in fact I got this code from a
working popup.
I think there's enough interest in this bug to reopen it for discussion,
but this is in no way a JavaScript Engine issue. I will reassign to 
the Browser-General component, and resummarize as per Comment #4.
Status: VERIFIED → REOPENED
Resolution: INVALID → ---
Summary: A new popup window is open although it's not permited in scripts preferences → Can use form.submit() to circumvent window.open() prefs
Reassigning to Browser-General for further discussion either way
on this issue -
Assignee: rogerl → Matti
Status: REOPENED → NEW
Component: JavaScript Engine → Browser-General
QA Contact: pschwartau → imajes-qa
-> Caps
Assignee: Matti → mstoltz
Component: Browser-General → Security: CAPS
QA Contact: imajes-qa → bsharma
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla1.1beta
*** Bug 146297 has been marked as a duplicate of this bug. ***
Although it is not a 'bug' in the Javascript Engine, it still defeats the
purpose of the popup-blocker.

I want to be able to open new windows if I click on a link. I do *not* want new
windows to open if I do *not* click on the link that opens the window myself!

This code opens a new window that is definitely 'unrequested' - so it should (if
at all possible) be blocked if a user has 'Open unrequested windows' disabled.



My idea how to fix this (I don't know how Mozilla works internally though, so
have no idea how hard this would be to implement): If the 'Open unrequested
windows' function is disabled, Javascript should not be able to submit forms
that have a not-yet-existing target (i.e. one that will open in a new windows).

This should be possible to do: the Javascript Engine knows which form it's going
to submit, so it can lookup it's target, and check whether that is an existing
window or frame.

Am I making sense here?
So you're saying that the "open link in new window" pref and the "open 
unrequested windows" pref should be a single pref, basically?  Yes, that's true.

Also see bug 126224 and bug 132031.
*** Bug 140239 has been marked as a duplicate of this bug. ***
*** Bug 152073 has been marked as a duplicate of this bug. ***
From dup bug 152073: if you uncheck the "allow web pages to open a link in a new
window" pref, the form submits to the same window instead of a new window.  That
would make sense if the form submit had been triggered by the user, but in this
case it means that an advertisement replaces the page.
> So you're saying that the "open link in new window" pref and the "open 
> unrequested windows" pref should be a single pref, basically?

Absolutely not. There is a difference between CLICKING a link that has a
"_blank" target, and a JS that does it "for me". As was said in comment #10  I
want to be able to click links and have a popup happen WHEN I CLICK, not when I
didn't do anything.

doubleclick is already exploiting this. Take a look at bug 158462. The JS taken
from the NY Times site where the doubleclick ad is located:

<script name="javascript">
		<!-- 
		function submitCCCForm()
			{
		PopUp = window.open('',
'_Icon','location=no,toolbar=no,status=no,width=650,height=550,scrollbars=yes,resizable=yes');
		this.document.cccform.submit();
			}
		// -->
		</script>
Blocks: 158464
*** Bug 152007 has been marked as a duplicate of this bug. ***
Futuring.
Target Milestone: mozilla1.1beta → Future
*** Bug 164399 has been marked as a duplicate of this bug. ***
OS: Linux → All
Hardware: PC → All
This is strange. I do not see any pop-up at all !

Maybe because 1.1 branch is not concerned ?
OS: All → Linux
Hardware: All → PC
More descriptive URL:
http://zetafleet.com/dev/bug/popup/index.shtml
(I do not have sufficient user rights to change the address)

Problem may have been resolved in nightly builds since 1.1b, but two nights' ago
build rendered Mozilla non-functional for me, and as such, I have been unable to
upgrade to a version later than 20020721.
*** Bug 167719 has been marked as a duplicate of this bug. ***
*** Bug 166953 has been marked as a duplicate of this bug. ***
Blocks: popups
I just ran into this behavior myself, and did enough bugzilla'ing to find this
report.  Maybe "popup" should be added to the summary to head off more dupes?

I'm running Mozilla 1.2b
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.2b) Gecko/20021016

The text of the Javascript is exactly the same (right down to "flauncher") of
the original reporter.
Following Todd's suggestion, added "popup blocking" to summary -
Summary: Can use form.submit() to circumvent window.open() prefs → Can use form.submit() to circumvent popup blocking, window.open() prefs
http://www.popupad.net/  advertising site that uses this trick
I'm using 1.3b, this problem still exists
http://www.land.ee/d_nimo_codec.html also uses this trick to do pop-ups.

Perhaps this is not just a pop-up issue. But an issue regarding the security of
allowing a webpage to call form.submit without the user taking any action to do so.

What reason would a website have to call a form.submit in the body onLoad beyond
spam / malicious actions?
> What reason would a website have to call a form.submit in the body onLoad 
> beyond spam / malicious actions?

Try the "bugzilla" form at http://www.cs.hmc.edu/~jruderma/s/ .  Calling
form.submit in onload is legit; opening a new window with an onload form.submit
is not.
But that page just takes data entered in a form, then creates another page,
processes the data in the URL, and then posts it in another form. It could
easily be done in just one page without that second auto-submit. Even with forms
requiring POST data rather than GET, it's still easy to do it all on one page.

Anyways... what's the fix? If form submit is called during the onLoad event,
then do not listen to the 'target' tag, open the page in the current window...

Also... to show the evil this issue can cause (make sure you've saved all your
data, cause this is going to kill Mozilla):
http://theedgeofforever.com/test.html
"Anyways... what's the fix? If form submit is called during the onLoad event,
then do not listen to the 'target' tag, open the page in the current window..."

Oh my, no, I think that would be even worse then the current situation!!

Imagine visiting a site that uses this popup 'trick', in that case the popup-ad
would replace the page you're looking at! That would, IMHO, even be several
orders of magnitude more annoying than getting the occasional popup window.

I think that when a page is submitted during javascript onLoad() with a
non-existing target (i.e. not the name one of the existing frames, but _BLANK or
some non-existing target that will make Mozilla open a new window), the submit
should just be thoroughly ignored.

That is, if the 'open unrequested windows' option is disabled in the prefs,
ofcourse.

I have made a small test-page at http://www.havinga.nu/popup.html . In my
opinion, this 'bug' will be fixed when the code on that page doesn't make the
Mozilla.org site pop up anymore. It *definitely* shouldn't be opening
Mozilla.org in the current window (overwriting whatever page you where viewing).
Mike Odom: http://www.cs.hmc.edu/~jruderma/quicksearch.html (the page that uses
form.submit onload) allows http://www.cs.hmc.edu/~jruderma/s/ to load more
quickly, and it allows me to make and use a "bug search" bookmarklet.
I'm using 1.3 and this problem has bitten me.  I agree with previous posters
that having a form automatically submit (to generate a popup) without any
warning is a security issue.
this BUG annoys me too... very very much. 

here's my suggestion for a fix:

instead of having this page submit automatically, when the line
"document.flauncher.submit();" is executed AND the form itself has either
"target='_new'" or "target='some_window_that_does_not-exist'", i think that the
form should not be submitted. Instead, a button should appear, maybe on the
taskbar or next to the title on the tab at the top. When you click on this
button, the form would finish submitting. The tooltip for this button should say
"A form submission was stopped. Click here to submit it now.". That way, no
functionality would be lost, and unauthorized popups would not occur.
*** Bug 202582 has been marked as a duplicate of this bug. ***
*** Bug 202920 has been marked as a duplicate of this bug. ***
*** Bug 203348 has been marked as a duplicate of this bug. ***
*** Bug 204315 has been marked as a duplicate of this bug. ***
*** Bug 204361 has been marked as a duplicate of this bug. ***
*** Bug 206535 has been marked as a duplicate of this bug. ***
*** Bug 206493 has been marked as a duplicate of this bug. ***
OS: Linux → All
Hardware: PC → All
Moving Popup Blocking bugs to XPApps, assigning to shliang
Assignee: mstoltz → shliang
Status: ASSIGNED → NEW
Component: Security: CAPS → XP Apps
*** Bug 208830 has been marked as a duplicate of this bug. ***
*** Bug 210474 has been marked as a duplicate of this bug. ***
*** Bug 211597 has been marked as a duplicate of this bug. ***
*** Bug 211659 has been marked as a duplicate of this bug. ***
The fix for bug 104470 might provide a clue for how to fix this bug.
Interested folks should upgrade to a trunk build post 20030625 for the fix.

*** This bug has been marked as a duplicate of 210560 ***
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → DUPLICATE
Blocks: pop-up-arms-race
No longer blocks: popups
Product: Core → Mozilla Application Suite
No longer blocks: 158464
You need to log in before you can comment on or make changes to this bug.