Closed Bug 144726 Opened 23 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: 23 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: 23 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.