Script space quota exhausted error when creating a large HTML block with jQuery constructor in Firefox

[elcarpie@…]

This bug report is similar to #6796, but in my case I'm passing a text block of HTML to the jQuery function instead of an unsupported XML block. That bug was marked as fixed, but the rather low limit still exists in Firefox.

In my case, I'm using the jstree plugin which is taking a rather large XML document (retrieved from a web service) and using XSLT to turn it to a string containing an HTML nested list, which it then passes to jQuery's constructor to create DOM objects. I get the "stack quota" error in the same RegExp call mentioned in #6796.

In #6796, dmethvin suggested assuming that anything over 1K is HTML. That seems reasonable to me (and works in my use case with a patched jQuery 1.4.4).

To reproduce, open ​http://jsfiddle.net/6GvyJ/ with Firefox (in my case 3.6.13) with Firebug enabled. The script simply dynamically creates a large string containing the html for an unordered list. I've tweaked the len variable to be right over the edge of Firefox's limit. Set len to 71859 and the script will work.

In Chrome, I was able to set len to several hundred thousand before I started having issues.

[jitter]

Thanks for taking the time to contribute to the jQuery project by writing a bug report.

This looks like a "bug" which IMHO isn't worth investing more time to fix it.

Especially since in FF 4.bX they finally seem to have improved the regex code and setting len to several hundred thousand works without issues (takes some time but works).

Also passing in html strings > 800kb isn't a very common thing to do and probably indicates some application logic problem. And finally a slightly adapted version of your test I made ​here works in FF 3.6.13 even with len > 200000.

For the moment being I leave this open if someone else wants to provide further input but I'm inclined to close this unless you yourself can provide a nice clean patch.

​http://docs.jquery.com/Getting_Involved

[elcarpie@…]

Thanks for the quick response!

It's good to hear the RegExp backtrack limitation with FF will be lifted in FF4. I'm in a corporate environment, so FF4 is at least a year away for my users.

I would agree that creating HTML from very large strings is not the norm, but I'm writing an internal web application (as opposed to web site) that deals with large data sets. The third party plugin I'm using, jstree, accepts XML data and uses the browser's xslt functionality to convert to an html string. It then creates the DOM objects from that by passing to jQuery. That is much faster than some sort of programmatic build up of the tree. So I'm inclined to keep using that method.

I was unaware of the fact that passing the string to append() did not suffer from the same limitation as passing the string to the jQuery function. I modified my copy of jstree and that worked around the issue. I will pass along that information to the jstree maintainer. Thanks for that tip!

So, I have a workaround that jstree may/may not accept, but one I can live with. If no action is taken on this and other users do hit the issue, the exception thrown isn't really helpful, which makes the issue problematic to find. As a result, I will patch with the >1024 bytes check and send a pull request from Github. You can then decide whether or not you want to include the change.

Thanks again for the response!

[jitter]

Thanks for the feedback. It's good to hear that you are going to be able to workaround this issue by using .append(html).

The reason $(html) suffers from this while $(elem).append(html) doesn't has something to do with the fact that $() needs to check for many more different kinds of input.

It would be great if you can submit a nice small pull for this which leaves as with more time on our hands to fix other things.

[elcarpie@…]

Submitted pull request: ​https://github.com/jquery/jquery/pull/192

[dmethvin]

Landed pull 292.