Last Comment Bug 309775 - (NS_ERROR_FAILURE) [nsIDOMJSWindow.open] error when opening windows with JavaScript
: (NS_ERROR_FAILURE) [nsIDOMJSWindow.open] error when opening windows with Java...
Status: RESOLVED FIXED
happens after opening many windows
: fixed1.8, regression, testcase
Product: Core
Classification: Components
Component: DOM: Core & HTML (show other bugs)
: Trunk
: All All
: -- major with 11 votes (vote)
: ---
Assigned To: Robert O'Callahan (:roc) (email my personal email if necessary)
: Hixie (not reading bugmail)
: Andrew Overholt [:overholt]
Mentors:
: 290924 291871 309170 309978 310074 310148 310243 310262 310526 311072 311077 311857 312057 312288 313112 313137 313148 313254 313478 313770 313795 314194 314437 314678 (view as bug list)
Depends on:
Blocks: 303484
  Show dependency treegraph
 
Reported: 2005-09-23 10:32 PDT by Brant Evans
Modified: 2006-03-12 18:56 PST (History)
48 users (show)
asa: blocking1.8b5-
asa: blocking1.8rc1+
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test page that demonstrates problem (5.58 KB, text/html)
2005-09-26 09:17 PDT, Brant Evans
no flags Details
test case: click and open quite a few popups, then they stop opening (1.45 KB, text/html)
2005-09-27 09:20 PDT, Robert Ames
no flags Details
simpler testcase, closes automatically. (891 bytes, application/xhtml+xml)
2005-09-28 22:14 PDT, Unknown W. Brackets
no flags Details

Description Brant Evans 2005-09-23 10:32:11 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.open]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame :: http://localhost/cgi-bin/homepage.pl
:: openwin :: line 36"  data: no]


The above error is reported in the JavaScript Console when I open webpages with
JavaScript.

I have a webpage that uses the following JavaScript to open several (about 20 at
a time) webpages in new windows. It will open between 8 and 10 pages and then
the above exception is thrown. To correct the problems and Firefox has to be
restarted otherwise other parts of firefox fail as well, for example the
Help->About Mozilla Firefox fails with this error:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.openDialog]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://browser/content/utilityOverlay.js :: openAboutDialog :: line 362" 
data: no]\


My JavaScript code:

          site_list = all_urls.split(";");

          url_list.blur();
          url_list.selectedIndex = 0;
          if ( site_list.length > minLength ) {
                countwindow =
window.open("","countwindow","left=10,top=10,width=300,height=100");
                countwindow.document.write("<HTML><HEAD>");
                countwindow.document.write("<TITLE>Opening Sites</TITLE>");
                countwindow.document.write("</HEAD><BODY bgcolor=008888>");
                countwindow.document.write("<H3 ID=TitleHead><center>Opening
Requested Sites</center></H3>");
                countwindow.document.write("<center><b><DIV
ID=CountLine></DIV></b></center>");
                countwindow.document.write("</BODY></HTML>");
          }
          //This launches a new window for each site in site_list
          for (var site = 0; site < site_list.length; site++) {
             sitenum = site + 1;
             //mywin[site] = window.open("", "",
"left=100,top=100,status,menubar,location,reesizable,scrollbars,toolbar");
             mywin[site] = window.open("", "");
             mywin[site].moveTo(100,100);
             mywin[site].blur();
             mywin[site].location = site_list[site];
             if ( site_list.length > minLength ) {
               countwindow.focus();
               countwindow.document.getElementById("CountLine").innerHTML =
'Opening window ' + sitenum + ' of ' + site_list.length;
             }
          }
          
          if ( site_list.length > minLength ) {
               countwindow.close();
          }

          for (var site = site_list.length - 1; site >= 0; site--) {
             mywin[site].focus();
          }
     }

The function is given a list of sites in this format:

http://www.ucomics.com/9to5/;http://www.ucomics.com/adamathome/;http://bbspot.com;http://www.ucomics.com/bottomliners/;http://www.ucomics.com/closetohome/;http://www.ucomics.com/compu-toon/;http://www.ucomics.com/cornered/;http://www.ucomics.com/foxtrot/;http://www.ucomics.com/fredbasset/;http://www.ucomics.com/garfield/;http://www.ucomics.com/helen/;http://www.humorscope.com/#sagittarius;http://www.ucomics.com/inthebleachers/;http://www.geekculture.com/joyoftech/index.html;http://www.ucomics.com/nonsequitur/;http://www.phdcomics.com/comics/comics.php;http://www.pvponline.com/;http://www.ucomics.com/shoe/;http://www.userfriendly.org/cartoons/archives/;http://www.ucomics.com/ziggy/

As a side not the MoveTo command is also not moving the windows to the location
specified.

Reproducible: Always

Actual Results:  
No more windows open after expection is thrown

Expected Results:  
windows would continue to open and be moved to the correct location on screen
Comment 1 zug_treno 2005-09-24 04:34:18 PDT
Related to bug 309170 comment 6, Core bug 177819 and/or Thunderbird bug 290924?
Comment 2 Nickolay_Ponomarev 2005-09-24 19:42:29 PDT
Could you attach a testcase? (see
http://www.mozilla.org/newlayout/bugathon.html#testcase )

Also, it is a regression over Firefox 1.0, right? (that's the impression I get
after reading comments in bug 290924)
Comment 3 Brant Evans 2005-09-26 09:17:11 PDT
Created attachment 197425 [details]
Test page that demonstrates problem
Comment 4 Brant Evans 2005-09-26 09:18:37 PDT
This is a regression from Firefox 1.0.x. This same JavaScript code has worked
perfectly on each 1.0.x release, but fails with 1.5 beta 1.
Comment 5 Nickolay_Ponomarev 2005-09-26 09:41:33 PDT
Wow, that's evil. Can't reproduce though: I get a number of errors in the
console, but not the window.open one. Does it happen using a clean Firefox profile?

BTW, is it possible to tune the testcase, so that it doesn't open 20 flashy
sites, like using the data: URL or something?
Comment 6 Jerome Lacoste 2005-09-26 23:24:57 PDT
I reproduce this issue every time on the following website:

http://www.lequipe.fr

if you go to the right side of the page in the "Chrono" panel, click on any of
the links inside this panel (which should popup a window using javascript),
nothing happens and the following error is found in the js console.

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.open]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://www.lequipe.fr/module_actualite.html :: MM_openBrWindow :: line 13" 
data: no]

About dialog doesn't work neither. Firefox 1.5beta1 on Linux. Never had the
issue with ff 1.0.x
Comment 7 Jerome Lacoste 2005-09-27 02:28:19 PDT
I forgot to mention an important fact: on a fresh start I don't see the issue.
But after a while (e.g. 1 day of browsing), I always end up seeing the problem.
Nothing special printed on the terminal where firefox was started from.
Comment 8 Nickolay_Ponomarev 2005-09-27 02:59:14 PDT
Okay, confirming per multiple other comments.

Can you reproduce it using a new profile, and if so, what settings need to be
changed?
Comment 9 Brant Evans 2005-09-27 08:35:42 PDT
I currently can't test with a clean profile as I've had to go back to 1.0.7 and
don't have time to install 1.5 and then go back to 1.0.7 and fix everything. If
I get a chance I will reinstall with a clean/new profile.

The only setting I had changed was dom.popup_maximum which I set arbitarily
large (100000).
Comment 10 Robert Ames 2005-09-27 09:18:10 PDT
bug 310148, bug 310074, bug 309978 should be marked as duplicates of this one.

Confirming here with test-case to attach (originally found via bug 310148).

"After a while, no popups work".  I'm on Mac, do not know if it's mac-specific,
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908
Firefox/1.4.

Appears to affect following calls: 
  nsIDOMJSWindow.open, nsIDOMJSWindow.openDialog, nsIDOMJSWindow.openSubFrame

I would recommend "blocker-ing" this bug (or one of it's duplicates that have
more information) as from the user's point of view it is intermittent, almost a
data-loss (can't bookmark all your tabs, must copy/paste manually) requires a
browser-restart, and has a reproduceable test-case.

Behaviour that I see is:
  - After clicking several window.open links

  - page/HTML popup windows no longer work (ie: window.open())

  - Certain mozilla windows no longer open:
     - Add Bookmark window
     - Connection Settings window (for changing proxies)
     - (these are both "sheet" windows on the mac

  - Following javascript errors:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.open]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
https://bugzilla.mozilla.org/attachment.cgi?id=197425 :: openwin :: line 33" 
data: no]

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.openDialog]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://browser/content/browser.js :: addBookmarkForTabBrowser :: line 1495" 
data: no]

Test case is attached.

Steps to reproduce:

  - Load Test-case file.

  - Click all links and close all windows (one or two times through all of them)

  - Eventually links stop popping up windows.

  - After this, bookmarks-add (ctrl-d) doesn't work (window does not show)

  - After this, preferences/connection-settings doesn't work

  - Errors as pasted get stuffed into js-console.
Comment 11 Robert Ames 2005-09-27 09:20:31 PDT
Created attachment 197570 [details]
test case: click and open quite a few popups, then they stop opening
Comment 12 Jennifer 2005-09-27 09:20:55 PDT
*** Bug 310074 has been marked as a duplicate of this bug. ***
Comment 13 Jennifer 2005-09-27 09:23:45 PDT
(In reply to comment #12)
> *** Bug 310074 has been marked as a duplicate of this bug. ***

To add to my report/duplication (my bug includes an example where a forum
"reply" button failed, the associated JS console error, and the URL, but you
have to have an account to try it), I'm a Mac user. Info:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908
Firefox/1.4 ID:2005090806
Comment 14 Nickolay_Ponomarev 2005-09-27 10:25:58 PDT
Robert: for bugs with testcases attached we use the testcase keyword, not the flag.
Comment 15 Phil Ringnalda (:philor) 2005-09-27 20:03:40 PDT
*** Bug 310262 has been marked as a duplicate of this bug. ***
Comment 16 Asa Dotzler [:asa] 2005-09-27 21:32:02 PDT
can one of you determine in which nightly build this regressed?
Comment 17 Phil Ringnalda (:philor) 2005-09-28 00:29:21 PDT
*** Bug 310243 has been marked as a duplicate of this bug. ***
Comment 18 Unknown W. Brackets 2005-09-28 01:35:20 PDT
I'm not sure which nightly build first regressed this, but it's been happening
to me for at least a month (since before 1.5 Beta 1 was released, iirc.)

This is very annoying, but a restart always cures it.  Strangely enough, it
seems to only happen for modal windows and window.open - in other words, things
like Help Contents and New Window work fine, as does opening a link in a new
window.  Alerts and confirms also do not show, and which even makes the "Later"
button of the "Apply Downloaded Update Now..." dialog cease to work.

Bug 290924 seems completely different.  I cannot get alert()s to work, even from
the JavaScript Console (which does show, itself.)  Its first comment also
describes behavior which does not happen for me (View Source shows fine, from
the console or otherwise.)

Bug 309170 seems exactly the same as what I experience (so perhaps this is a
dupe of that, or that a dupe of this.)

I'm not sure about bug 177819, since its reproduction steps are... long.  No
such steps are required to reproduce this bug.

I'm going to do some testing with nightlies, the trunk, and see what I can find.

-[Unknown]
Comment 19 Henrik Skupin (:whimboo) 2005-09-28 02:49:59 PDT
Peterv, could it be a regession which was raised by the changes for the JS
engine? Perhaps one of the security fixes or just by the inner and outer windows?

Without diving deeper into the problem in one of that functions the assertion
has to be raised:
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#4176
Comment 20 Henrik Skupin (:whimboo) 2005-09-28 02:51:30 PDT
Peterv, please see comment 19. I forot to CC you.
Comment 21 Unknown W. Brackets 2005-09-28 22:14:44 PDT
Created attachment 197806 [details]
simpler testcase, closes automatically.

Okay, some testing has revealed this only happens with the Web Developer
extension installed and enabled (at least, for me.)

With it enabled, I get only a few (10 - 20) window.open()'s before none work at
all.  While I have been using this extension for quite a while (over a year),
it's possible an update to it or a change (one that isn't a bug, I mean) in
Firefox caused it.

On another note, I got this while testing:

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]"  nsresult:
"0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame ::
chrome://browser/content/browser.js :: BrowserShutdown :: line 878"  data: no]

Which happens only with this testcase (rapid open and close via JavaScript.) 
Is it worth filing a bug?  (I found some which were related, but different and
already fixed.)

Is anyone seeing these problems without the Web Developer extension
(http://chrispederick.com/work/webdeveloper/) installed and enabled?

-[Unknown]
Comment 22 Jennifer 2005-09-28 22:24:06 PDT
I do have Web Developer. Does anyone else here not have it?

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050928
Firefox/1.4 ID:2005092806 with WebDev 0.9.4. I have disabled it (as of the next
restart) and it will be interesting to see if this problem goes away.
Comment 23 Brant Evans 2005-09-28 22:55:56 PDT
I also had the Web Developer extension installed.
Comment 24 Jennifer 2005-09-28 23:10:52 PDT
I've sent a message with a link to this bug to the author of the extension. I
don't want to add him as a cc without consent (and the contact info on the site
is a form, anyway).
Comment 25 Chris Pederick 2005-09-28 23:24:52 PDT
I am the author of the Web Developer extension and I just tried the "simpler
testcase" with both Web Developer 0.9.4 and my unreleased alpha version with
Firefox 1.5b1 on Mac and I was able to open over a 100 windows.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050908
Firefox/1.4

The extension adds an event listener for page loads, but otherwise shouldn't be
doing anything that breaks opening new windows.

I don't have access to a Windows machine tonight, but can check on a Windows box
in the morning. Am I missing something in my testing?
Comment 26 Marc Bauer 2005-09-29 00:26:39 PDT
Chris, i saw errors from your extension, too. but only after FX starts 
producing problems on all other pages, too. i think this starts after i 
pressed the "Edit CSS". this hasn't opened the CSS and only a blank sidebar. i 
don't know if this is caused by Webdeveloper - but i don't think so.
Comment 27 Mikhail Kashkin 2005-09-29 01:44:49 PDT
I'm have WDExt too. Even if dont touch it after restart of FF.
Comment 28 Chris Pederick 2005-09-29 09:41:16 PDT
Okay - I just tested this again on Windows using the simpler testcase:

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

And I still wasn't able to reproduce the problem. However, I then realized that
I had the "Force links that open new windows to open in a new tab" option
checked. Once I disabled this I was able to reproduce the problem and disabling
Web Developer made it go away.

I'll see if I can spend some time today tracking down what exactly in Web
Developer is causing this.
Comment 29 Jennifer 2005-09-29 10:09:07 PDT
Did it reproduce for Mac as well? 
Comment 30 Chris Pederick 2005-09-29 10:26:51 PDT
I'm at work now so I don't have access to my Mac, but I am guessing it was the
same problem that I had the same preference set on my Mac which is why I
couldn't reproduce the problem. If I disable that preference on the Mac then I
bet I would start seeing the problem.
Comment 31 Henrik Skupin (:whimboo) 2005-09-29 10:57:03 PDT
*** Bug 290924 has been marked as a duplicate of this bug. ***
Comment 32 Henrik Skupin (:whimboo) 2005-09-29 11:10:47 PDT
*** Bug 309978 has been marked as a duplicate of this bug. ***
Comment 33 Henrik Skupin (:whimboo) 2005-09-29 11:12:25 PDT
*** Bug 310148 has been marked as a duplicate of this bug. ***
Comment 34 Chris Pederick 2005-09-29 11:19:13 PDT
Okay - so I have tracked down the problem, although I don't know why it is
causing a problem or whether it is a bug in the Web Developer code.
Unfortunately, I don't have the time at work to create simple test extension to
demonstrate this, but I may have time to do that this weekend unless someone
else can do it before then.

Basically I have a line in the Web Developer overlay JS that calls an initialize
method when the extension starts:

window.addEventListener("load", webdeveloper_initialize, true);

The stripped down version of webdeveloper_initialize() looks like this:

function webdeveloper_initialize(event)
{
    var consoleService =
Components.classes["@mozilla.org/consoleservice;1"].getService().QueryInterface(Components.interfaces.nsIConsoleService);

    if(consoleService)
    {                
        try
        {
           
consoleService.unregisterListener(WebDeveloperJavaScriptConsoleListener);
        }
        catch(exception)
        {
            // Do nothing
        }

        consoleService.registerListener(WebDeveloperJavaScriptConsoleListener);
    }

    // Try to remove the event listener
    try
    {
        window.removeEventListener("load", webdeveloper_initialize, true);
    }
    catch(exception)
    {
        // Do nothing
    }
}

And the stripped down console listener looks like this:

var WebDeveloperJavaScriptConsoleListener =
{
    // Observes changes in the console
    observe: function(error)
    {
        return false;
    }
}

If I comment out the line:

consoleService.registerListener(WebDeveloperJavaScriptConsoleListener);

Then the problem goes away. Am I doing something wrong with my JavaScript
console listener?
Comment 35 Henrik Skupin (:whimboo) 2005-09-29 11:26:12 PDT
*** Bug 309170 has been marked as a duplicate of this bug. ***
Comment 36 Henrik Skupin (:whimboo) 2005-09-29 11:42:42 PDT
With Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20050926
Firefox/1.6a1 and Web Developer 0.9.4 I can't see that assertion on my Linux
box. Anyone whose using Linux and can reproduce it?

Chris, I cannot detect any mistake you should have been made. IMHO it's raised
somewhere deeper.
Comment 37 Phil Ringnalda (:philor) 2005-09-29 19:44:22 PDT
*** Bug 310526 has been marked as a duplicate of this bug. ***
Comment 38 Asa Dotzler [:asa] 2005-09-30 12:48:11 PDT
This appears to be a problem that only impacts the web developer extension
users. If that's the case, then we're not going to block beta on this.
Comment 39 Marc Bauer 2005-09-30 14:09:46 PDT
Asa, Webdeveloper is THE extension... we realy need it and it must work. if 
there is somthing in FX killing the extension - this must be fixed ASP. if 
not - we are not able to "use" and support FX. i'm sure i'm talking for all 
webdevelopers if i say this. webdeveloper has become the greated tool out 
there...
Comment 40 Henrik Skupin (:whimboo) 2005-09-30 14:33:43 PDT
(In reply to comment #39)
> Asa, Webdeveloper is THE extension... we realy need it and it must work. if 
> there is somthing in FX killing the extension - this must be fixed ASP. if 
> not - we are not able to "use" and support FX. i'm sure i'm talking for all 
> webdevelopers if i say this. webdeveloper has become the greated tool out 
> there...

Anyone who encounter problems with that extension should try it out with a
completely fresh installation of Firefox and a new profile. Make three steps:

* Test without Webdeveloper installed
* Install webdeveloper and test again
* If it happens again, try to disable Webdeveloper and uninstall it for a
further test without any extension.

If this issue only appears for the second step, we need to hurry up to find a
solution. For myself I can't do anything, cause all is working fine for me with
Webdeveloper installed.
Comment 41 Thomas Spear 2005-09-30 18:10:36 PDT
This may be an issue in FF 1.5 beta, but bug 290924 was reported while 1.5 was
still in alpha..  Before the majority of the public (including myself) even knew
about it.  So I'm posting this note here to let you know that it has been an
issue even in the 1.0.x series.  The bug mentioned above affects a 1.0.x series
extension, prior to the extension maintainer adding FF 1.5 support, although it
does still affect the extension after he added that support.
Comment 42 Martijn Wargers [:mwargers] (not working for Mozilla) 2005-10-03 11:29:07 PDT
I've filed bug 310955 for the nsIObserverService.removeObserver js error
mentioned in comment 21.
Comment 43 Jennifer 2005-10-04 15:42:45 PDT
It just happened again, without WebDev enabled...

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.open]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://www.blackwell-synergy.com/templates/jsp/_synergy/script.js :: newWindow
:: line 273"  data: no]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20050930
Firefox/1.4 ID:2005093005
Comment 44 Henrik Skupin (:whimboo) 2005-10-04 22:51:22 PDT
(In reply to comment #43)
> It just happened again, without WebDev enabled...

Can you also give as the URI and which steps we have to do to reproduce it?
Comment 45 Jennifer 2005-10-04 23:00:53 PDT
(In reply to comment #44)
> (In reply to comment #43)
> > It just happened again, without WebDev enabled...
> 
> Can you also give as the URI and which steps we have to do to reproduce it?

It was an article from the science journal Traffic, on a page like this:

http://www.blackwell-synergy.com/doi/abs/10.1034/j.1600-0854.2003.00135.x

click on the "PDF" button to try to download the PDF version of the paper. It
uses JavaScript to spawn the window. (It's a "free content" paper so you don't
have to be on a university campus or other subscribed location to get it)
Comment 46 Adam Guthrie 2005-10-05 11:39:49 PDT
*** Bug 311072 has been marked as a duplicate of this bug. ***
Comment 47 Jennifer 2005-10-05 11:56:46 PDT
And here's another report.

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.open]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
http://ly.lygo.com/ly/wired/news/js/global.js :: popChild :: line 229"  data: no]

Wired News: Photoshop Magic Melts Prison Bars
(http://www.wired.com/news/culture/0,1284,69035,00.html)

(click on a photo thumbnail on the left side of the page)
Comment 48 Phil Ringnalda (:philor) 2005-10-10 23:43:26 PDT
*** Bug 311857 has been marked as a duplicate of this bug. ***
Comment 49 Christian Schmidt 2005-10-11 01:22:08 PDT
Another symptom that I think hasn't been mentioned: When this problem kicks in,
regular links that open new windows, i.e. <a href="foo.html" target="_blank">
don't work either.
Comment 50 Alistair Potts 2005-10-11 04:21:02 PDT
My experience is that it kicks in after fifty to sixty openings of pop-ups. So I
don't think pointing to a specific URL is going to help debugging.

This is making my web applications very difficult to use, since I use pop-ups as
sub-windows quite a lot. Eventually they just stop. Only a restart of the whole
application re-enables them.
Comment 51 Alistair Potts 2005-10-11 04:23:30 PDT
Sorry, I should have added that I can confirm that this has been going on since
1.0x, not just the new 1.5 betas.
Comment 52 Phil Ringnalda (:philor) 2005-10-11 07:43:29 PDT
While there may be other issues that have been going on forever, this particular
issue regressed between 20050813 and 20050820. It would be a big help if someone
with time and bandwidth enough would download the builds from between those
dates from http://archive.mozilla.org/ to track down which day is the first one
affected.

I can't help thinking it's suspicious that while tracking it down that far, I
didn't get "10 or 20" before failure from attachment 197806 [details], I got exactly 12
every time, in a couple dozen tries in different builds.
Comment 53 Mike Kaply [:mkaply] 2005-10-11 08:34:28 PDT
*** Bug 311077 has been marked as a duplicate of this bug. ***
Comment 54 Chris Pederick 2005-10-11 09:15:22 PDT
Re: Comment 52 - In my testing with that attachment it was also consistently
failing for me on number 12.
Comment 55 Mike Kaply [:mkaply] 2005-10-11 09:43:12 PDT
Intersting. I get it to fail at 12 consistently as well, but ONLY if I have the
Google resize search bar extension turned on. If I have that extension turned
off, I do not see the problem.
Comment 56 Mike Kaply [:mkaply] 2005-10-11 12:34:02 PDT
The actual failure is here:

http://lxr.mozilla.org/seamonkey/source/embedding/components/windowwatcher/src/nsWindowWatcher.cpp#611

if (weAreModal) {
  rv = queueGuard.Push();


queueGuard.Push is failing

still looking.
Comment 57 Mike Kaply [:mkaply] 2005-10-11 12:40:11 PDT
Actual failure is here:

http://lxr.mozilla.org/seamonkey/source/xpcom/threads/nsEventQueue.cpp#558

      if (depth > MAX_EVENTQUEUE_NESTING_DEPTH)
        return NS_ERROR_FAILURE;

depth is 0x0D (13)

MAX_EVENTQUEUE_NESTING_DEPTH is 13

This would certainly explain the "12" issue - somehow opening and closing those
windows is causing event queue nesting to 12.
Comment 58 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-10-11 12:52:39 PDT
That would make this a regression from bug 303484 then, correct?
Comment 59 Mike Kaply [:mkaply] 2005-10-11 13:08:21 PDT
I backed out the patch from bug 303484 and build and this problem goes away.

So this is definitely a regression from that bug.
Comment 60 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-10-11 13:10:51 PDT
Hmm.

I wonder what's going on. If the queues are really nested that deep, that's a
serious problem on its own; you'll eventually run out of stack space and crash.

There's no test page that doesn't require an extension to be installed, I guess?
Comment 61 Jennifer 2005-10-11 13:14:54 PDT
(In reply to comment #60)

> There's no test page that doesn't require an extension to be installed, I guess?

Originally, it seemed to be the case that this was caused by Web Developer.
However, it seems that that was just a coincidence, since I've gotten this
without WebDev, and I think others have as well. Just browse around; I've left a
few test pages in earlier comments for people to try.
Comment 62 Boris Zbarsky [:bz] (still a bit busy) 2005-10-11 15:18:16 PDT
So the basic problem is that opening a content window is not atomic.  Appshell
opens the window, starts the toplevel XUL loading, pushes an event queue, then
spins it until the XUL is done loading.  Then gets the window for the
content-primary browser out of the new XUL document, and returns that to the caller.

So while the XUL is loading, we're spinning the event queue... and more
window.open calls can happen, which will push new event queues, etc.  If I
recall correctly, event queues hold refs to their elders, so a queue cannot
remove itself from the chain, even if it has been deactivated and has no events,
until all younger queues are gone... (I thought I'd filed a bug on this, but I
can't find it now).
Comment 63 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-10-11 16:35:27 PDT
Another reason to get rid of event queue nesting altogether!

I think we should probably just back out bug 303484. It's the simplest,
lowest-risk thing we can do. Any kind of change to the way window opening works
will definitely be neither simple nor low-risk. It does mean someone could
produce stack overflows but those are not security critical.
Comment 64 Joshua B. 2005-10-12 15:04:50 PDT
I can confirm that this also happens in Firefox 1.5 Beta 2 while using
Authorize.Net's merchant interface when clicking the capture button. It most
often occurs when several other tabs are open.

Error: uncaught exception: [Exception... "Component returned failure code:
0x80004005 (NS_ERROR_FAILURE) [nsIDOMJSWindow.open]"  nsresult: "0x80004005
(NS_ERROR_FAILURE)"  location: "JS frame ::
https://account.authorize.net/ui/themes/anet/merch.app?page=history&sub=detail
:: createXML :: line 135"  data: no]

I removed the session id, merchant id, and transaction id from the URL
referenced above.
Comment 65 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-10-12 15:52:45 PDT
Boris, Brendan, can you comment on comment #63?
Comment 66 Nickolay_Ponomarev 2005-10-13 08:45:02 PDT
*** Bug 312288 has been marked as a duplicate of this bug. ***
Comment 67 Asa Dotzler [:asa] 2005-10-13 19:14:04 PDT
setting the blocking nomination flag so that the team managing the 1.5 release
can evaluate.
Comment 68 Boris Zbarsky [:bz] (still a bit busy) 2005-10-13 20:33:47 PDT
I agree on the risk analysis of touching window opening.  Given that, if this is
biting real sites (which it seems to be), then I agree that backing out bug
303484 for 1.8 is probably the way to go.  :(

Alternately, we could keep the cap we added for bug 303484 but raise it.  A lot.
Enough that we still prevent stack overflow in general, but that running into
the limit would be very hard.  That's assuming that we can compute such a value;
if we can't, then just backing out is probably the safest thing to do.
Comment 69 Brendan Eich [:brendan] 2005-10-13 20:40:46 PDT
(In reply to comment #68)
> Alternately, we could keep the cap we added for bug 303484 but raise it.  A lot.
> Enough that we still prevent stack overflow in general, but that running into
> the limit would be very hard.  That's assuming that we can compute such a value;

Why not use the JS thread stack limit set by DOM code to conservatively bound
stack depth?  We would need to call a thin JS API addition, or just #include
"jscntxt.h" and use JS_CHECK_STACK_SIZE directly.  Lxr that macro for example
uses in the JS engine.

/be
Comment 70 Phil Ringnalda (:philor) 2005-10-13 21:33:46 PDT
I see by reading back through the bug that it's not clear that this isn't
actually site-related at all, just a dozen window.open related: you don't need a
popup cannon like in comment 0 or the testcase, you can just slowly wander
through a dozen different sites opening one popup in each. So however large we
make MAX_EVENTQUEUE_NESTING_DEPTH, it looks to me like that would be a hard
limit on how long Web Developer toolbar users could run a particular instance of
Firefox.
Comment 71 Boris Zbarsky [:bz] (still a bit busy) 2005-10-13 21:41:46 PDT
Er...  So what you're saying is that web developer toolbar manages to leak event
queues, right?  Have you filed a bug on them about that?

Note that the idea here would be to limit at the point where we'd crash due to
stack overflow otherwise.  So the only thing that would "break" is that instead
of the "expected" crash you'd get an exception instead.
Comment 72 Unknown W. Brackets 2005-10-13 22:11:39 PDT
(In reply to comment #71)
> Er...  So what you're saying is that web developer toolbar manages to leak event
> queues, right?  Have you filed a bug on them about that?
> 
> Note that the idea here would be to limit at the point where we'd crash due to
> stack overflow otherwise.  So the only thing that would "break" is that instead
> of the "expected" crash you'd get an exception instead.

It seems many are reporting that this happens with other extensions installed
and/or with no extensions installed in some cases.  I have not experienced it
since disabling the web developer toolbar (which I normally find very useful)
but I do not use many extensions, nor many sites that use popups.  See comment 61.

But of course, I would agree that making it crash again is a bad solution.  It's
one thing (one clearly bad thing) if clicking a link silently does nothing, it's
another if it crashes all my browser windows (even if that is much later.)

If I may ask, what is the realistic limit to where a crash would be expected for
eventqueue nesting?  Just past 12?  More like 48 or 96?

It took me, usually, several hours of casual browsing to trigger the 12 limit. 
It would seem to me that if that could be doubled, still with no risk of
crashing, most people (or at least I) wouldn't so easily notice the problem -
extension or not.

-[Unknown]
Comment 73 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-10-13 22:28:41 PDT
The thing is, I'm not aware of any stack overflow crash reports that that fix
actually would have prevented. Is anyone else?
Comment 74 Phil Ringnalda (:philor) 2005-10-13 22:51:45 PDT
Sigh. Sometimes I can do decent QA, other times I'm thick as a brick.

Chris: you leak like a sieve! If you're going to grab the console service in
your load handler, you need to also free it in your unload handler. Put
|consoleService.unregisterListener(WebDeveloperJavaScriptConsoleListener);|
(wrapped with suitable if()s and try{}s) in |function webdeveloper_pageUnload()|
and attachment 197806 [details] can open 200+ popups without any WebDev problems.

Jennifer and anyone else who has seen it without WebDev: now's a good time to
speak up, and describe exactly how: that you completely uninstalled the Web
Developer toolbar extension, and verified that your profile didn't have a
/extensions/{c45c406e-ab73-11d8-be73-000a95be3b12}/ directory any more, or
created a clean profile, and were still able to repeat the problem, because I
can't, despite opening two dozen popups on every site that's been mentioned here
and in duplicates.
Comment 75 Alistair Potts 2005-10-14 03:09:14 PDT
There's an icon that you can use web webdev (looks like a cog) that hides/shows
the toolbar - hiding it doesn't turn it off in any way so that might be the
cause of some of the confusion whether it's a webdev issue or not.

Disabling the webdev with webdev's right-most circle-triangle icon allowed me to
open up 20+ windows. Re-enabling webdev caused failure at 12. Once this failure
point is reached, disabling webdev doesn't allow any more openings.
Comment 76 Mike Kaply [:mkaply] 2005-10-14 07:30:14 PDT
I see this with the search resize extension.

What should I look for to see the leak?

Here's their JS code:

const ResizeSearchBox = {
  pref: null,
  MIN_WIDTH: 40,          //minimum width of the searchbox
  THRESHOLD_HEIGHT: 100,  //max vertical distance travelable before we abort the
drag gesture
  sBox: null,             //searchbox reference
  dragging: false,
  ltr: true,
  startX: 0,
  startY: 0,
  sLen: 0,

  startup: function() {
    const r = ResizeSearchBox;
    r.pref =
Components.classes["@mozilla.org/preferences-service;1"].getService(Components.interfaces.nsIPrefBranch);
    r.refreshBox();
  },

  destroy: function() {
    const r = ResizeSearchBox;
    r.pref = null;
    r.sBox = null;
    window.removeEventListener("load", r.startup, false);
  },

  refreshBox: function() {
    const r = ResizeSearchBox;

    r.sBox = document.getElementById("search-container");

    if(!r.sBox) {
      r.pref.setIntPref("browser.search.searchbox.width", 140);  //reset mechanism
      return false;
    }

    if(!r.sBox.width) {
      r.sBox.width = r.pref.getIntPref("browser.search.searchbox.width");
      return false;
    }

    return true;
  },

  startDrag: function(aEvent, ltr) {
    const r = ResizeSearchBox;

    if(aEvent.button == 0) {
      if(!r.refreshBox())return;  //need to check search box incase user removes
it from the toolbar

      r.startX = aEvent.clientX;
      r.startY = aEvent.clientY;
      r.dragging = true;
      r.ltr = ltr;

      r.sLen = r.sBox.width;  //store original width for calculations

      window.addEventListener("mousemove", r.whileDrag, true);
      window.addEventListener("mouseup", r.endDrag, true);
    }
  },

  whileDrag: function(aEvent) {
    const r = ResizeSearchBox;

    if(r.dragging) {
      var dX = aEvent.clientX - r.startX;
      var dY = aEvent.clientY - r.startY;

       //If the pointer wanders too far while dragging
       //we will assume it was an accidental drag and abort.
      if(Math.abs(dY) > r.THRESHOLD_HEIGHT) {
        r.clearDrag(true);
        return;
      }

      if(!r.ltr)dX *= -1;

      if(r.sLen - dX > r.MIN_WIDTH) {
        r.sBox.width = r.sLen - dX;
      }

    } else r.clearDrag(true);
  },

  endDrag: function(aEvent) {
    const r = ResizeSearchBox;
    r.clearDrag(false);
    r.pref.setIntPref("browser.search.searchbox.width", r.sBox.width);
  },

  clearDrag: function(revert) {
    const r = ResizeSearchBox;

    r.dragging = false;
    window.removeEventListener("mousemove", r.whileDrag, true);
    window.removeEventListener("mouseup", r.endDrag, true);

    if(revert)r.sBox.width = r.sLen;
  }
}

window.addEventListener("load", ResizeSearchBox.startup, false);
window.addEventListener("unload", ResizeSearchBox.destroy, false);
Comment 77 Jennifer 2005-10-14 09:11:51 PDT
(In reply to comment #72)

> If I may ask, what is the realistic limit to where a crash would be expected for
> eventqueue nesting?  Just past 12?  More like 48 or 96?

I don't think we should have ANY limit whatsoever on how many popups a session
can open. I like to leave Firefox open for long periods of time, and I often use
forums where the reply function works by opening a popup window in which the
reply is typed; the window closes when the submit button is clicked. I reach the
max limit very, very quickly with these kinds of forums and I shouldn't have to
restart Firefox multiple times just to be able to use the sites. I can't see how
it would be acceptable for an application to work only for a short time before
it has to be restarted.

(In reply to comment #74)

> Jennifer and anyone else who has seen it without WebDev: now's a good time to
> speak up, and describe exactly how: that you completely uninstalled the Web
> Developer toolbar extension

It's disabled, not uninstalled. Is not disabling an extension supposed to keep
it from having any effect on the app, since it isn't loaded anymore and its only
presence is its listing in the extensions box, tagged as "disabled"? I still
seem to get popup death even with WebDev disabled.

(In reply to comment #76)

> I see this with the search resize extension.

I have this extension also, and have disabled it just earlier today (but haven't
tested to see if popups quit on me as yet) because I just don't seem to get the
widget anymore (it's vanished from my toolbar and also from the 'customize
toolbar' window, making it entirely useless) in the build I am using now, which is:

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b5) Gecko/20051012
Firefox/1.4.1 ID:2005101205
Comment 78 Scott MacGregor 2005-10-14 11:17:30 PDT
There's a lot going on in this bug. Trying to summarize for the triage team:

roc, bz and others are in favor of just backing out Bug 303484 to fix this
problem. If anyone is strongly objecting to that, speak up now otherwise we'll
end up doing that.
Comment 79 Boris Zbarsky [:bz] (still a bit busy) 2005-10-14 13:03:05 PDT
> I don't think we should have ANY limit whatsoever on how many popups a session
> can open. 

No one's suggesting that.
Comment 80 Mike Kaply [:mkaply] 2005-10-17 11:24:00 PDT
I am now hitting this without the search resize extension. I hit it just messing
with some XUL apps at:

http://www.georgenava.com/applauncher.php

Are we going to get this backed out for 1.5rc1?
Comment 81 Asa Dotzler [:asa] 2005-10-17 11:44:42 PDT
Robert, can you back out your patch at bug 303484 so we can clear this from our
blocker list? Thanks.
Comment 82 Chris Pederick 2005-10-17 13:59:59 PDT
(In reply to comment <a
href="https://bugzilla.mozilla.org/show_bug.cgi?id=309775#c74">#74</a>)

Whenever I register a listener I try to unregister any previous listener just
beforehand to stop multiple listeners. Shouldn't this be doing exactly what you
are suggesting anyway? This is what the code looks like in Web Developer 0.9.4:

// If not already listening to the console
if(!webdeveloper_javaScriptConsoleListener)
{
    const consoleService =
Components.classes["@mozilla.org/consoleservice;1"].getService().QueryInterface(Components.interfaces.nsIConsoleService);

    // Try to unregister the listener
    try
    {
        consoleService.unregisterListener(WebDeveloperJavaScriptConsoleListener);
    }
    catch(exception)
    {
        // Do nothing
    }

    consoleService.registerListener(WebDeveloperJavaScriptConsoleListener);

    webdeveloper_javaScriptConsoleListener = true;
}

In the next release of the extension I have rewritten this code to make it a
little tidier anyway, but I want to make sure I know exactly why the extension
may be exposing this problem.

It sounds as though this isn't just Web Developer related either so other
extension authors may be making similar mistakes.
Comment 83 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-10-17 18:50:05 PDT
I backed out 303484 on trunk and branch. Resolving this FIXED.
Comment 84 Luca M. 2005-10-20 04:40:35 PDT
*** Bug 313112 has been marked as a duplicate of this bug. ***
Comment 85 Peter van der Woude [:Peter6] 2005-10-20 07:47:34 PDT
*** Bug 313137 has been marked as a duplicate of this bug. ***
Comment 86 Phil Ringnalda (:philor) 2005-10-20 08:37:57 PDT
*** Bug 313148 has been marked as a duplicate of this bug. ***
Comment 87 Phil Ringnalda (:philor) 2005-10-23 09:36:10 PDT
*** Bug 313478 has been marked as a duplicate of this bug. ***
Comment 88 Peter van der Woude [:Peter6] 2005-10-28 10:43:54 PDT
*** Bug 314194 has been marked as a duplicate of this bug. ***
Comment 89 Phil Ringnalda (:philor) 2005-10-29 19:10:21 PDT
*** Bug 313478 has been marked as a duplicate of this bug. ***
Comment 90 Nickolay_Ponomarev 2005-10-31 14:09:38 PST
*** Bug 312057 has been marked as a duplicate of this bug. ***
Comment 91 Nickolay_Ponomarev 2005-11-01 08:20:16 PST
*** Bug 313795 has been marked as a duplicate of this bug. ***
Comment 92 Robert Ames 2005-11-02 11:28:11 PST
verified fixed in:

  Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8)
  Gecko/20051025 Firefox/1.5

...using RC-1 which I picked up today-ish (2005-11-02).  Ran through 110 popup windows from the "Simpler Test Case".  All seemed to work well.

--Robert
Comment 93 Phil Ringnalda (:philor) 2005-11-06 11:37:51 PST
*** Bug 314437 has been marked as a duplicate of this bug. ***
Comment 94 :Gavin Sharp [email: gavin@gavinsharp.com] 2005-11-23 11:23:13 PST
*** Bug 314678 has been marked as a duplicate of this bug. ***
Comment 95 Nickolay_Ponomarev 2005-12-09 03:51:59 PST
*** Bug 313254 has been marked as a duplicate of this bug. ***
Comment 96 Nickolay_Ponomarev 2005-12-09 03:55:29 PST
*** Bug 313770 has been marked as a duplicate of this bug. ***
Comment 97 Ryuichi KUBUKI 2005-12-24 06:14:58 PST
*** Bug 291871 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.