Closed Bug 144726 Opened 22 years ago Closed 20 years ago
Can use form
.submit() to circumvent popup blocking, window .open() prefs
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 # ?
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
QA Contact: pschwartau → imajes-qa
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. ***
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.
*** Bug 152007 has been marked as a duplicate of this bug. ***
Target Milestone: mozilla1.1beta → Future
*** Bug 164399 has been marked as a duplicate of this bug. ***
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. ***
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
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. ***
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 → 20 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.