[patch] The iframe transport gets confused if a chunk ends with a newline

[GoogleCodeExporter]

If the contents of an element ends with one or more newlines, IE ignores these 
in the innerText attribute. Therefore, if the server should decide to 
chunk/flush the output right after a newline and jquery-stream tries to parse 
this chunk, it will get confused.

Attached is a simple Perl CGI script which intentionally flushes a message 
right after a newline, along with a tiny HTML document that alert()s new 
messages. Try this in IE to see the problem. (I have only tested in IE 8, but i 
assume other version of IE have the same problem)

I have also attached a patch with a possible solution to the problem. This 
patch duplicates the element containing the data and adds one non-newline 
character to it before it reads its innerText. This way, the last characters in 
the innerText attribute is never a newline, and IE is happy. Only tested in IE 
8.

Original issue reported on code.google.com by haake...@gmail.com on 7 Jul 2011 at 11:09

Attachments:

• jquery.stream.js.patch
• index.html
• test

[GoogleCodeExporter]

Yes, you're right.

In fact, when jQuery Stream was 0.x version, the message format was 'length 
\r\n data \r\n' that came from the chunk expression of the Chunked Transfer 
Coding in HTTP 1.1. On account of the issue like you mentioned above, then I 
did replace \r\n with ;. The reason why I didn't preserve \r\n is the 
performance.

Anyway, from now on, jQuery Stream 1.2 will no longer requires the current 
response and message format, so the server response must be preserved. Thanks, 
I almost missed this point.

The attached patch however is likely to be slow. If the response is hundreds of 
kilobytes, a series of operations such as cloneNode, innerText, substring, 
innerText and length is too tough for IE6 or IE7 to execute them. Of course, 
it's not common case.

Thanks for report and patch.

Original comment by flowersi...@gmail.com on 8 Jul 2011 at 5:32

• Added labels: Target-1.2, Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Have you actually tested whether it is slow or not? Even with the patch, my IE 
8 has no problem with messages of several megabytes (unlike Firefox, which is 
really struggling). Your code emties the element after reading its contents, so 
most of the time cloneNode, etc works with really small elements, even though 
the message is large. 

However, you are of course free to fix it the way you think is best, and maybe 
it is slower in older versions of IE.

Thank you for creating this nice library. 

Btw, related to performance: Have you considered increasing the interval in the 
iterate-function to something like 20-50ms? I haven't looked closely at it, but 
I would assume it could decrease cpu usage without introducing any noticeable 
delays in most cases.

Original comment by haake...@gmail.com on 8 Jul 2011 at 3:51

[GoogleCodeExporter]

The performance criteria I used before is a arrival time difference of a 
message between when using script tags in text/html response and when using 
setTimeout text in text/plain response. As the latter I think technically 
cannot help being more tardy than the classical former, I concentrated on 
minimizing this gap. 

I'll test it with your patch and consider increasing the interval as well.

Thanks for your advice.

Original comment by flowersi...@gmail.com on 9 Jul 2011 at 7:49

[GoogleCodeExporter]

fixed in r118

Thanks for great patch.

Original comment by flowersi...@gmail.com on 11 Jul 2011 at 9:28

• Changed state: Fixed