293940 - alert displays blank dialog when string contains >= 5460 chars without a space

Status: NEW

(Core :: Layout, defect)

Description

[Yuriy Shiklhanovich]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4

While developing a piece of web software I came across this bug. When i try to
escape a certain length string in javascript using escape(String). The result
comes out blank. Although I am able to get the .length of it. I wrote sample
code that produces this problem every time. http://dev.viapeople.com/escapeTest.html

I was able to also reproduce this problem in FireFox 1.0.4 & Netscape 7.2, but
not IE 6.0

Reproducible: Always

Steps to Reproduce:
1. Go to http://dev.viapeople.com/escapeTest.html
2. Click on the "Click Me" Button
3. The 4th alert box will have the bad string.

Actual Results:  
Empty looking string. I'm assuming the object is malformed, as I can still get
it's length.

Expected Results:  
Display the proper escaped string

Comment 1

[Josh Birnbaum]

I don't know if it's correct, but I see output with Mozilla 1.8b.  Please try a
more recent version of the code; Firefox 1.0.x is a relatively old code-base.

Comment 2

[Brendan Eich [:brendan]]

When did we drop the DOM escape and unescape, which were based on bad buggy old
Netscape versions that used the document's charset?

/be

Comment 3

[Bob Clary [:bc] (inactive)]

It's not escape. The limit is on the number of characters in a row without a
breaking space before alert craps out and doesn't display the contents of the
string. The limit is 5460. Less than that and the alert displays. equal or
greater and it displays blank. 

Comment 4

[Bob Clary [:bc] (inactive)]

Attachment: testcase

Comment 5

[Yuriy Shiklhanovich]

Attachment: This one writes the string to a DIV. Try selecting the text.

Bob Clary suggested that this maybe a limitation of the alert() function. So I
re-wrote the html file so that the string also gets written to a div. Besides
not being visible, it's got some strange behaviour when it's selected
(highlighted?).

Comment 6

[Bob Clary [:bc] (inactive)]

Attachment: testcase 2

Ok, this probably is about more than just alert. It has to do with how adjacent
text nodes are displayed in a variety of situations.

This test takes the input string in |test|, puts its escaped value into
|escaped|, then creates a string |underscore| by replacing each '%' in
|escaped| by '_'. 

|underscore| is placed into a div using innerHTML. In the DOM, the string is
split into two text nodes: 4096 bytes, and 176 bytes. This displays properly. 

|escaped| is placed into a div using innerHTML. In the DOM, the string is split
into two text nodes: 4096, bytes, and 176 bytes. The first text node fails to
display,but if you scroll over to the right you can see the second text node.

I don't know why the presence of the '%' makes a difference here.

Note also that in the case where a textarea element contains more than 4096
characters, its value will also not display its contents.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Interesting...  The testcases seem to work fine for me with a GTK1 build, but my
GTK2 builds show the problem.  Could just be a matter of the fonts used, though.
 A debug GTK2 build gives me:

###!!! ASSERTION: bad width: 'metrics.width>=0', file
../../../mozilla/layout/generic/nsLineLayout.cpp, line 1071

on the first testcase of this bug, so it sounds like the width of the textframe
just overflows our nscoords.

In testcase 2, I bet the underscore char is just narrower than the percent char;
using 'W' instead of '_' shows the same problem as with '%'.

To layout; roc, what's the number of that bug about using float for nscoord?