The default bug view has changed. See this FAQ.

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

RESOLVED FIXED

Status

()

Core
DOM: Core & HTML
--
major
RESOLVED FIXED
12 years ago
11 years ago

People

(Reporter: Brant Evans, Assigned: roc)

Tracking

({fixed1.8, regression, testcase})

Trunk
fixed1.8, regression, testcase
Points:
---
Bug Flags:
blocking1.8b5 -
blocking1.8rc1 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: happens after opening many windows)

Attachments

(3 attachments)

(Reporter)

Description

12 years ago
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

12 years ago
Related to bug 309170 comment 6, Core bug 177819 and/or Thunderbird bug 290924?

Comment 2

12 years ago
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
(Reporter)

Comment 3

12 years ago
Created attachment 197425 [details]
Test page that demonstrates problem
(Reporter)

Comment 4

12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
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

12 years ago
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
(Reporter)

Comment 9

12 years ago
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

12 years ago
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+

Comment 11

12 years ago
Created attachment 197570 [details]
test case: click and open quite a few popups, then they stop opening

Comment 12

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

Comment 13

12 years ago
(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

12 years ago
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. ***

Comment 16

12 years ago
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. ***

Comment 18

12 years ago
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.

Comment 21

12 years ago
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

12 years ago
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.
(Reporter)

Comment 23

12 years ago
I also had the Web Developer extension installed.

Comment 24

12 years ago
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

12 years ago
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

12 years ago
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

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

Comment 28

12 years ago
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

12 years ago
Did it reproduce for Mac as well? 

Comment 30

12 years ago
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. ***

Comment 34

12 years ago
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. ***

Comment 38

12 years ago
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-

Comment 39

12 years ago
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.

Comment 41

12 years ago
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.

Comment 43

12 years ago
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?

Comment 45

12 years ago
(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

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

Comment 47

12 years ago
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. ***

Comment 49

12 years ago
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

12 years ago
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

12 years ago
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.

Comment 53

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

Comment 54

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

Comment 55

12 years ago
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

12 years ago
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

12 years ago
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?

Comment 59

12 years ago
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?

Comment 61

12 years ago
(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.

Comment 64

12 years ago
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?

Comment 66

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

Updated

12 years ago
Flags: blocking1.8rc1?
Keywords: qawanted

Updated

12 years ago
Flags: blocking1.8rc1? → blocking1.8rc1+

Comment 67

12 years ago
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.

Comment 72

12 years ago
(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.

Comment 75

12 years ago
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

12 years ago
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

12 years ago
(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

12 years ago
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.

Comment 80

12 years ago
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

12 years ago
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+

Comment 82

12 years ago
(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
Last Resolved: 12 years ago
Resolution: --- → FIXED
Keywords: fixed1.8

Comment 84

12 years ago
*** 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. ***

Comment 90

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

Comment 91

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

Comment 92

12 years ago
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. ***

Comment 95

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

Comment 96

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

Comment 97

11 years ago
*** 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.