Ext.DomQuery.selectValue() 4k limit

Ext.DomQuery.selectValue() 4k limit - only in FF

FF has a limit of 4k of text in one text node.
selectValue() doesn't consider this.

For more info you can read at:
http://www.webmasterworld.com/javascript/3388031.htm

Ok, so why are you reporting that as a bug in Ext?

Suppose I have a <node>with more than 4k of text</node>
Ext.DomQuery.selectValue('node') will return only first 4k of text.

I think it's a bug, because in the methods code you just fetches only firstChild, correct is by fetching all text nodes, right ?

I made a simple example which proves my point.

This is a test page:

Code:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> <title>FF 4K limit in TextNode</title> <script type="text/javascript" src="/res/ext/base.js"></script> <script type="text/javascript" src="/res/ext/ext-all-debug.js"></script> <script type="text/javascript"> Ext.onReady(function(){ var s = new Ext.data.Store({ proxy: new Ext.data.HttpProxy({url: 'data.xml'}), reader: new Ext.data.XmlReader({ record: 'item', }, [ 'test' ]) }); s.on("load", function(store, records, options) { console.log(records[0].get("test")); Ext.get("result").update(records[0].get("test")); }); s.load(); }); </script> </head> <body> <div id="result"></div> </body> </html>

and here is data.xml:

Code:

<Data> <item> <test>Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing... Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing... Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing... Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing... Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing... Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing... Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing... Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing... Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing... Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Here is the end.....Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...Testing...</test> </item> </Data>

As you can see only first 4k of text is loaded.

We will look at addressing this in 2.0. I prefer to avoid it as it is important that the performance of selectValue does not suffer. In the meantime, I recommend using select and processing the value manually for your extra large nodes.

Just out of curiosity, is this simply an academic question, or are you actually hitting this as an issue in your application?

Thank you for your answers.

Yes, actually I'm hitting this issue with my app.
Here is a workaround:

Code:

var result = ~some_node~ var response = ""; for (var i = 0, len = result.childNodes.length; i < len; i++) { response += result.childNodes[i].nodeValue; }

Check out this post over at http://www.quirksmode.org/bugreports...ode_maxim.html

using [object].normalize() on the returned XML will fix the problem.

We hit the same issue when returning large Node's, and fixed it using this.

Quote:

Originally Posted by Klausy

Check out this post over at http://www.quirksmode.org/bugreports...ode_maxim.html

using [object].normalize() on the returned XML will fix the problem.

We hit the same issue when returning large Node's, and fixed it using this.

nice find =D>

Here is the solution

You can refer to the following link

http://ytotare.blogspot.com/2011/09/...-overflow.html