Closed Bug 249979 Opened 21 years ago Closed 21 years ago

window.open() fails to open popup window after a while

Categories

(SeaMonkey :: General, defect)

Product:
SeaMonkey
Component:
General
Platform:
x86
Windows XP
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8alpha2

People

(Reporter: wolfgang.dinstl, Assigned: danm.moz)

References

Details

(Keywords: fixed-aviary1.0, fixed1.7.5)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040616 Block unrequested popup windows is unchecked, so that popups are allowed. Javascript below executes fine for 21 times, but then the new window object is not present anymore. <HTML> <head> </head> <body onload="msv_open();"> TEST MOZILLA <script> function msv_open() { if (confirm("go on ?")) { var nwindow = window.open("file://C:/mozilla.htm"); if (nwindow == null) { alert("new window object not available!"); }; } } </script> </body> </html> Reproducible: Always Steps to Reproduce: 1. Copy HTML-code into a file c:/mozilla.htm 2. Load file://c:/mozilla.htm 3. press go on for 21 times -> then the alert is shown! Actual Results: window object is not present Expected Results: window object should be present (like in 1.6) Happens only in 1.7, not in previous versions.
The number 21 is what caught my eye with this one. If you look at the release notes for Mozilla 1.7 (http://www.mozilla.org/releases/mozilla1.7/README.html#new), under the New Features section there is this: Even without a UI, users should notice a greater variety of pop-ups blocked (primarily mouseover pop-ups) and a limit of 20 or so open at one time - regardless of whether pop-up blocking is active. This will provide some protection from sites that open hundreds of windows in a loop. It would appear your page is getting stopped by the enhanced popup blocker. I've been trying to find the bug for that feature but I have been unsuccessful. Bug 197919 looks close to what is being described.
Found bugid 247421 http://bugzilla.mozilla.org/show_bug.cgi?id=247421 might be related.
The behaviour of popup-blocking is very bad in scenario of web-applications, where javascript is rendered in "onload"-event of body-tag to open a new window. Is it not allowed to submit a page and then render the page again with javascript to open a new window as response to the user´s submit action? Further, I think the "close" of a window does not reduce the number of popups opened! So if a user works some time with an application which behaves like described above, he will run into this popup-blocking problem sooner or later.
*** Bug 252593 has been marked as a duplicate of this bug. ***
This was done intentionally, to protect even people who don't want to use the popup blocker from being savaged by jerk website authors who open popups in loops. I'm prepared to believe it's a mistake that it can't be turned off. Tell me again what's so different about these things you call "web-apps," and why they have a legitimate need to open dozens of popup windows, would you? Do you want to open all these windows at once, or >Further, I think the "close" of a window does not reduce the number of popups >opened! So if a user works some time with an application which behaves like is this the problem, that you open one at a time and eventually run into the limit? Can you point me to a sample site?
Assignee: general → danm.moz
Status: UNCONFIRMED → NEW
Ever confirmed: true
I created a little sample to demonstrate what happens: This sample consists of 2 pages. The first one opens a new named window in onload-event of body-tag (2nd page is opened). The 2nd page only displays the search part of the URL. Please press RELOAD-Button for 20 times and then close the new window and press RELOAD-button again. Then you run into the new enhanced popup blocking feature. This is only a demonstration what happens. It´s easy to imagine, that this happens in a web-app scenario,for example browsing through a number of rows and displaying some detail in a new window. Page 1: <HTML> <head> </head> <body onload="msv_open();"> <script> function msv_open() { var nwindow = window.open("new.htm?" + Math.random(),"newwin"); if (nwindow == null) { alert("popup blocked!"); return; } window.focus(); } </script> The button reloads the page. Onload opens a new window with name "newwin".<br> Please click 20 times and then close the new window.<br> And then click again. <button onclick="location.reload(true);">RELOAD</button> </body> </html> Page 2: <html> <head> <title>new window</title> </head> <body onload="document.write(location.search);"> </body> </html>
Agreed, that part is certainly a bug. It's been fixed as part of bug 247421. No release build has the fix yet, but it's in any trunk or Firefox 0.9 nightly build 20040705 or later, and any Mozilla 1.7 nightly build 20040722 or later. Regarding motivation: in real life the example you gave as "page 1" happens as part of a form submission, right? Please try one of the nightly builds (perhaps the 2004-07-26-11-1.7 branch build) and let me know if you have any problems. By the way, you can adjust the dom.popup_maximum pref to bring the problem on more quickly than the 20th time.
Yes, you are right. "Page 1" happens as part of a form submission in real life. OK, I will try a nightly build. By the way, I know about the dom.popup_maximum pref, but I wanted to demonstrate the default behaviour.
I tried 2004-07-26-11-1.7 branch build and it seems to work fine.
If there are no other issues we'll deem this fixed by bug 247421.
Status: NEW → RESOLVED
Closed: 21 years ago
Depends on: 247421
Keywords: fixed-aviary1.0, fixed1.7.3
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.8alpha2
So for those of us who don't want to upgrade to 1.8a3 because we find it too buggy, setting dom.popup_maximum to 0 would appear to disable the new feature that is causing the problem and be a suitable workaround.
(In reply to comment #11) > So for those of us who don't want to upgrade to 1.8a3 because we find it too > buggy, setting dom.popup_maximum to 0 would appear to disable the new feature > that is causing the problem and be a suitable workaround. Actually make that -1, not 0
Product: Browser → Seamonkey
*** Bug 238892 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.