Closed Bug 309775 Opened 19 years ago Closed 18 years ago

(NS_ERROR_FAILURE) [nsIDOMJSWindow.open] error when opening windows with JavaScript

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: branic, Assigned: roc)

References

Details

(Keywords: fixed1.8, regression, testcase, Whiteboard: happens after opening many windows)

Attachments

(3 files)

Test page that demonstrates problem
5.58 KB, text/html
Details
test case: click and open quite a few popups, then they stop opening
1.45 KB, text/html
Details
simpler testcase, closes automatically.
891 bytes, application/xhtml+xml
Details 
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
Related to bug 309170 comment 6, Core bug 177819 and/or Thunderbird bug 290924?
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)
Assignee: nobody → general
Component: General → DOM: Level 0
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → 1.8 Branch

    
    

    
  
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.

    
    

    
  
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?

    
    

    
  
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

    
    

    
  
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.

    
    

    
  
Okay, confirming per multiple other comments.

Can you reproduce it using a new profile, and if so, what settings need to be
changed?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b5?
Keywords: regression
Whiteboard: happens after opening many windows

    
    

    
  
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).

    
    

    
  
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.
Flags: testcase+

    
    

    
  
*** Bug 310074 has been marked as a duplicate of this bug. ***

    
    

    
  
(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

    
    

    
  
Robert: for bugs with testcases attached we use the testcase keyword, not the flag.
Flags: testcase+
Keywords: testcase

    
    

    
  
*** Bug 310262 has been marked as a duplicate of this bug. ***

    
    

    
  
can one of you determine in which nightly build this regressed?
Keywords: qawanted
Summary: (NS_ERROR_FAILURE) [nsIDOMJSWindow.open] error when opening windows with javacript → (NS_ERROR_FAILURE) [nsIDOMJSWindow.open] error when opening windows with JavaScript

    
    

    
  
*** Bug 310243 has been marked as a duplicate of this bug. ***

    
    

    
  
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]

    
    

    
  
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

OS: Windows XP → All
Hardware: PC → All
Version: 1.8 Branch → Trunk

    
    

    
  
Peterv, please see comment 19. I forot to CC you.

    
    

    
  


  
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]

    
    

    
  
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.

    
    

    
  
I also had the Web Developer extension installed.

    
    

    
  
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).

    
    

    
  
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?

    
    

    
  
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.

    
    

    
  
I'm have WDExt too. Even if dont touch it after restart of FF.

    
    

    
  
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.

    
    

    
  
Did it reproduce for Mac as well? 

    
    

    
  
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.

    
    

    
  
*** Bug 290924 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 309978 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 310148 has been marked as a duplicate of this bug. ***

    
    

    
  
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?

    
    

    
  
*** Bug 309170 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
*** Bug 310526 has been marked as a duplicate of this bug. ***

    
    

    
  
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.
Flags: blocking1.8b5? → blocking1.8b5-

    
    

    
  
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...

    
    

    
  
(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.

    
    

    
  
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.

    
    

    
  
I've filed bug 310955 for the nsIObserverService.removeObserver js error
mentioned in comment 21.

    
    

    
  
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

    
    

    
  
(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?

    
    

    
  
(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)

    
    

    
  
*** Bug 311072 has been marked as a duplicate of this bug. ***

    
    

    
  
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)

    
    

    
  
*** Bug 311857 has been marked as a duplicate of this bug. ***

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
*** Bug 311077 has been marked as a duplicate of this bug. ***

    
    

    
  
Re: Comment 52 - In my testing with that attachment it was also consistently
failing for me on number 12.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
That would make this a regression from bug 303484 then, correct?

    
    

    
  
I backed out the patch from bug 303484 and build and this problem goes away.

So this is definitely a regression from that bug.

    
    

    
  
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?

    
    

    
  
(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.

    
    

    
  
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).
Blocks: 303484

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
Boris, Brendan, can you comment on comment #63?

    
    

    
  
*** Bug 312288 has been marked as a duplicate of this bug. ***

    
  
Flags: blocking1.8rc1?
Keywords: qawanted

    
  
Flags: blocking1.8rc1? → blocking1.8rc1+

    
    

    
  
setting the blocking nomination flag so that the team managing the 1.5 release
can evaluate.
Flags: blocking1.8rc1+ → blocking1.8rc1?

    
    

    
  
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.

    
    

    
  
(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

    
    

    
  
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.

    
    

    
  
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.


    
    

    
  
(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]

    
    

    
  
The thing is, I'm not aware of any stack overflow crash reports that that fix
actually would have prevented. Is anyone else?

    
    

    
  
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.

    
    

    
  
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.

    
    

    
  
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);

    
    

    
  
(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

    
    

    
  
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.

    
    

    
  
> I don't think we should have ANY limit whatsoever on how many popups a session
> can open. 

No one's suggesting that.

    
    

    
  
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?

    
    

    
  
Robert, can you back out your patch at bug 303484 so we can clear this from our
blocker list? Thanks.
Assignee: general → roc
Flags: blocking1.8rc1? → blocking1.8rc1+

    
    

    
  
(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.

    
    

    
  
I backed out 303484 on trunk and branch. Resolving this FIXED.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED

    
    

    
  
*** Bug 313112 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 313137 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 313148 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 313478 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 314194 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 313478 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 312057 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 313795 has been marked as a duplicate of this bug. ***

    
    

    
  
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

    
    

    
  
*** Bug 314437 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 314678 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 313254 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 313770 has been marked as a duplicate of this bug. ***

    
    

    
  
*** Bug 291871 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.