Microsoft Infopath web forms no longer work. Get Error: script stack space quota is exhausted in the Error Console.




JavaScript Engine
8 years ago
3 years ago


(Reporter: Bob C, Assigned: Robert Sayre)



Windows Server 2003

Firefox Tracking Flags

(blocking2.0 betaN+, blocking1.9.2 -, status1.9.2 wanted)




8 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9.1b99) Gecko/20090605 Firefox/3.5b99 (.NET CLR 3.5.30729)

Was okay at FF 3.0.5, upgraded to 3.6 and MicroSoft Infopath no longer works. Get Error: script stack space quota is exhausted in the Error Console. 

Reproducible: Always

Steps to Reproduce:
1. Create a MS InfoPath browser form
2. Publish the form to a SharePoint server
3. Navigate to a new or existing form
Actual Results:  
Get Error: script stack space quota is exhausted in the Error Console. 

Expected Results:  
Form should display as it did in FF3.0.x

See also


8 years ago
Assignee: nobody → general
Component: General → JavaScript Engine
Product: Firefox → Core
QA Contact: general → general


8 years ago
Ever confirmed: true
Bob, are you willing to try narrowing down when this behavior changed?
blocking1.9.2: --- → ?
blocking2.0: --- → ?
status1.9.2: --- → ?
Keywords: qawanted, regression, regressionwindow-wanted
Or at least attaching the relevant web page to this bug?

Comment 3

8 years ago
Boris,  Sure, I reverted to 3.0.18 and it works.  I can try the next version of FF until it breaks.

Also, since this problem site is not accessible on the internet, I dont know the best way to demo the problem.  I can send the rendered aspx page if that'd help, or error consol details.
Bob, if saving the relevant page as "web page, complete" makes the problem appear when it is then loaded from a file:// URI, and you can attach the page and its required files (saved in something_files if the page is in something.html), then that would be very helpful.

If not, then yeah, figuring out whether this works in Firefox 3.5 would be a good start.  After that we can work on narrowing things down to the exact day the problem started happening...

Comment 5

8 years ago
3.1b3 worked, 3.5 breaks it.
Bob, does changing the "javascript.options.jit.content" preference to "false" change the behavior?

Comment 7

8 years ago
Still broke.  I'm on 3.5 now.  Should I be testing .vs Minefield?

Comment 8

8 years ago
Still broke with "javascript.options.jit.content" preference to "false"
that is...
OK.  So 3.1b3 came off the 1.9.1 branch around March 6, 2009.  Firefox 3.5 final shipped off the same branch around June 30, 2009.  That's about 3 months, so should take about 7 tests to narrow things down (if you divide the range in 2 every time), right?

You should be able to find 1.9.1 branch nightly builds at in the per-month directories.  In those, look for the *-mozilla-1.9.1 directories.  So for example the build in is the April 2 build.

If you're willing to use those to narrow down when the problem appeared, that would be wonderful!

Comment 10

8 years ago
I'll test and get back to you.
Wanted, for now, but not blocking as this seems to be a years-old regression. If that context changes (or a regression range is found) please renominate. By all means also nominate a patch for approval if one presents itself, with tests, well baked!
blocking1.9.2: ? → -
status1.9.2: ? → wanted

Comment 12

8 years ago
I confirm to have found the same problem in FF 3.6.3 for Mac (the latest version at this point).  I run eval() on a JSON 1611243 bytes in length and get the "script stack space quota is exhausted" message.

Comment 13

8 years ago
I'll find out where this regressed.
Assignee: general → sayrer


8 years ago
blocking2.0: ? → beta1+

Comment 14

8 years ago
Getting the same error on a FF 3.5.9 for Mac instance.
We tried to retrieve a large document (27.907.022 Bytes) via loadXMLDoc, which ends up in an InternalError exception with the "script stack space quota is exhausted" message.
Tobias, can you attach a page showing the problem to this bug?  The lack of an obvious way to reproduce is the thing most getting in the way of diagnosing this.


7 years ago
blocking2.0: beta1+ → beta2+

Comment 16

7 years ago
I'm running into the same issue when loading a 3.4MB XML file using JQuery, and have created a minimal example that reproduces the problem:

1 - Open in Firefox
2 - After a few seconds check the error console

Expected - The XML file should be loaded and parsed
Actual - The code fails with the message 

Error: script stack space quota is exhausted
Source File:
Line: 21

The same page runs with no problems in Safari 5.0 and Chrome 6.0. 
My full Firefox version is 

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.6; en-US; rv: Gecko/20100625 Firefox/3.6.6

You can download a zip of the source files at

Comment 17

7 years ago
Any suggestions on how I can help with the resolution of this bug? I've released the project it's affecting, and you can visit for a real-world example of the problem

Is regression testing the most useful thing I can do or ...?
Hmm.  For some reason I didn't get mail for comment 16...

In any case, the testcase in comment 16 shows the exception in Firefox 3.0.  Which means it's a different issue than what this bug was filed on; this bug was about something that used to work in Firefox 3.0 and then stopped working.  Pete, can you please file a separate bug on your issue (and mention its number here)?

Still waiting on Bob for feedback on his original problem...
What's worth mentioning in the bug you file is that what happens is that execution of the relevant regexp needs more than 65MB of backtrack stack data, which is what makes you get the error message.  The relevant js_ReportOutOfScriptQuota call is PushBackTrackState here:

3520            btincr = JS_ROUNDUP(btincr, btsize);
3521            JS_ARENA_GROW_CAST(gData->backTrackStack, REBackTrackData *,
3522                               &gData->cx->regexpPool, btsize, btincr);
3523            if (!gData->backTrackStack) {
3524                js_ReportOutOfScriptQuota(gData->cx);

That's using the testcase from comment 16.

Comment 20

7 years ago
Thanks Boris. I've spun off a new bug at and included your notes. I'll also be contacting the JQuery team to see if they have any input. I appreciate your help here.


7 years ago
blocking2.0: beta2+ → betaN+
I tried the STR in comment 16 and comment 17, and it WFM. Correct me if I'm wrong.
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME
Issue is resolved - clearing old keywords - qa-wanted clean-up
Keywords: qawanted, regressionwindow-wanted
You need to log in before you can comment on or make changes to this bug.