[BLOCKER][CRASH] Form doesn't send data when more than 16KB are submitted

VERIFIED FIXED in M12

Status

()

Core
HTML: Form Submission
P1
blocker
VERIFIED FIXED
19 years ago
18 years ago

People

(Reporter: gerardok, Assigned: rpotts (gone))

Tracking

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: help wanted, URL)

Attachments

(5 attachments)

(Reporter)

Description

19 years ago
Overview Description: When you try to submit a form that contains more than 16KB
of data in a single hidden/text input or textarea fields, it fails to send that
data to the server and it hangs the browser.

Hidden fields may contain large amounts on application generated data. I tried
posting 64KB (four times more than the above) using 4.5 or pre-Necko builds, and
the data is sent without a flaw.

Steps to Reproduce:

1) Click on the URL provided and verify you have access to the cgi script. It
will respond as "Welcome to Bubblegum Server!".

If you cannot access to bubblegum, download the attached cgi script and put it
on a web server directory with cgi execution privileges.

2) Load the attached testcase, or create an HTML file with the following
contents, and *wait* (10~20 sec. on Win NT) until it loads :

<HTML>
<HEAD>
<TITLE>Data Length Submission Test</TITLE>
</HEAD>
<BODY>

<FORM ACTION="/gerardok/cgi/cgitest.cgi" METHOD="post">
<INPUT TYPE="hidden" NAME="myname">
<INPUT TYPE="submit">
</FORM>

<SCRIPT type="text/javascript">

// Generate text for ~17KB
for( i = 65; i < 82; i++ ) {

  //10 char alphabetic string
  var s = "";
  var c = String.fromCharCode(i);
  for( k = 0; k < 10; k++ ) {
    s += c;
  }

  //Generate ~1000 char string
  for( j = 0; j < 100; j++ ) {
    document.forms[0].myname.value += s;
  }
  document.forms[0].myname.value += "<br>";

}

alert( "Page loaded" );
</SCRIPT>
</BODY>
</HTML>

3) When the page is loaded, an alert msg. will be displayed. Press the Ok button
to close that dialog box.

4) Click on the Submit button, and wait (5~10 sec. on Win NT) for the cgi
response.

Actual Results: The browser window hangs.

Expected Results: The submitted data should be displayed right below Bubblegum's
greeting Msg.

Build ID & Platform Bug Found: 1999-08-30-10-M10 on Win NT

Additional Builds and Platforms Tested On: 1999-08-30-01 on Linux, and
1999-08-30-09 on Mac.

Additional Information: Use hidden input only on Linux, as the UI widgets aren't
holding much data there because another bug.

Load the second attached testcase that sends only ~16KB, in order to demostrate
a successful data submission.
(Reporter)

Updated

19 years ago
Assignee: karnaze → gagan
QA Contact: cpratt → gerardok
(Reporter)

Comment 1

19 years ago
Created attachment 1515 [details]
cgi script
(Reporter)

Comment 2

19 years ago
Created attachment 1516 [details]
testcase
(Reporter)

Comment 3

19 years ago
Created attachment 1517 [details]
testcase showing successful data submission
(Reporter)

Updated

19 years ago
Priority: P3 → P1
(Reporter)

Comment 4

19 years ago
Updating attached testcases. I've forgot to update the server name for form
submission. In the above HTML, where it reads:

<FORM ACTION="/gerardok/cgi/cgitest.cgi" METHOD="post">

It should read:

<FORM ACTION="http://bubblegum/gerardok/cgi/cgitest.cgi" METHOD="post">
(Reporter)

Comment 5

19 years ago
Created attachment 1518 [details]
testcase take2
(Reporter)

Comment 6

19 years ago
Created attachment 1519 [details]
testcase showing successful data submission - take 2
(Reporter)

Updated

19 years ago
Severity: critical → blocker
Summary: [CRASH] Form doesn't send data when more than 16KB are submitted → [BLOCKER][CRASH] Form doesn't send data when more than 16KB are submitted
(Reporter)

Comment 7

19 years ago
This is preventing the automated tests from submitting test results when the
data to be sent is longer than 16KB. 8/24 and past Necko builds failed to submit
the data but it didn't crash the browser, but since 8/27 build it crashes and
stops automation. Updated Severity and Summary fields to reflect this.

Updated

19 years ago
Status: NEW → ASSIGNED
Whiteboard: help wanted
Target Milestone: M12

Comment 8

19 years ago
should be a small one to track down. need some volunteers for this one.

Updated

19 years ago
Assignee: gagan → rpotts
Status: ASSIGNED → NEW

Comment 9

19 years ago
rick is fixing a similar related problem of having the input stream being
created before opening the connection to the socket. Am letting him take this.
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

19 years ago
I've checked in a bunch of changes to both HTTP and the underlying socket
transport to fix this problem...

The test case now works fine in viewer (it also used to work in apprunner until
I updated to the tip).  The crash in apprunner is related to the modal dialog
box that the page displays after loading :-(

-- rick

Updated

19 years ago
Blocks: 17432
(Reporter)

Updated

18 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 11

18 years ago
Verified on 1999-12-17-13-M12 build on Win NT, and 1999-12-15-08-M12 build on
Mac 8.6.

Updated

18 years ago
No longer blocks: 17432
You need to log in before you can comment on or make changes to this bug.