78980 - pasting very long strings into text field crashes the browser

Status: RESOLVED WORKSFORME

(Core :: Layout: Form Controls, defect, P3)

Description

[Vladimir Ermakov]

Copy a string, like one of the lines in this report and paste it into one of the 
fields(summary for example). Hold the CTRL+V, soon you will no longer be able to 
see the text, it will become invisible, and then after more pastes ***CRASH*** 
build 2001-05-04-04-trunk windows 98

Linux doesnt crash, but it freezes... not much better.

Comment 1

[rods (gone)]

reassigning

Comment 2

[kinmoz]

I'll take a look at this one.

Comment 3

[rubydoo123]

easily repro on win 98using opt build 2001051404, I get the crash, get a dialog
box that staes an illegal operation occured and either hit Close or Ignore,
choosing ignore, I get the 'normal' error dialog box. Not stacktrace is triggered.

Comment 4

[shrirang khanzode]

I tried to repro this till my fingers ached (keeping CTRL+V pressed). Finally 
the textfield became blank..butI saw no crash. Vladimir, is this working for 
you?

Comment 5

[kinmoz]

I'm seeing the same thing shrir is seeing (no crash, but eventually blank) in my 
debug builds. At some point while pasting, we reach a limit in layout, and 
layout starts spewing out all sorts of debug data out to the console. You don't 
see this output in QA builds, but I imagine it is at that point that things stop 
rendering.

I'm thinking the reported crash might be related to the data corruption/crash 
reported in bug 74383.

Comment 6

[rubydoo123]

I am no longer crashing, remvoing crash keyword and pushing over to 9.2

Comment 7

[Vladimir Ermakov]

[e-mail] Although the behaviour seems fixed on linux Redhat I am still 
crashing on build 2001-05-22-06-trunk windows 98!

Comment 8

[rubydoo123]

using the build 2001052720, on win98 I do not crash

Comment 9

[Vladimir Ermakov]

crashing 2001-05-29-09-trunk windows 98... interesting I got a white box asking 
if I want to close the program or ignore it before the windows 98 crash dialog 
poped up.

Comment 10

[rubydoo123]

ok vladimire was able to show us the crash, I am attaching a testcase that can 
be used to reproduce this crash.

Comment 11

[rubydoo123]

Attachment: use this for the test case

Comment 12

[rubydoo123]

1. copy the testcase to your local drive and open in a plaintext editor
2. go to http://www.excite.com
3. copy the content of the testcase and paste into the search text widget

instacrash! there are 28,200 characters in the testcase.

Comment 13

[Simon Fraser [no longer active]]

Attachment: Testcase: input with very long value

Comment 14

[rubydoo123]

and I am attaching a test case with 2 input fields, one without a maxlength and 
one with.

Comment 15

[rubydoo123]

Attachment: testcase with and without maxlength (long string of text too)

Comment 16

[kinmoz]

I can't reproduce the crash under a Debug Win32 build, but running under purify, 
I see something suspicious when loading the 05/30/01 09:28 testcase. I'm not 
sure if it's related or not, I'll keep digging.



[E] ABR: Array bounds read in nsJISx4501LineBreaker::Next(WORD 
const*,UINT,UINT,UINT *,int *) {20 occurrences}
        Reading 2 bytes from 0x08fba6a0 (2 bytes at 0x08fba6a0 illegal)
        Address 0x08fba6a0 is 1 byte past the end of a 9824 byte block at 
0x08fb8040
        Address 0x08fba6a0 points to a C++ new block in heap 0x047a0000
        Thread ID: 0xb5
        Error location
            nsJISx4501LineBreaker::Next(WORD const*,UINT,UINT,UINT *,int *) 
[nsJISx4501LineBreaker.cpp:502]
            nsTextFrame::ComputeWordFragmentWidth(nsIPresContext 
*,nsILineBreaker *,nsLineLayout&,nsHTMLReflowState const&,nsIFrame *,nsIContent 
*,nsITextContent *,int *,WORD const*,UINT&,UINT) [nsTextFrame.cpp:5336]
            nsTextFrame::ComputeTotalWordWidth(nsIPresContext *,nsILineBreaker 
*,nsLineLayout&,nsHTMLReflowState const&,nsIFrame *,int,WORD *,UINT,UINT) 
[nsTextFrame.cpp:5261]
            nsTextFrame::MeasureText(nsIPresContext *,nsHTMLReflowState 
const&,nsTextTransformer&,nsILineBreaker 
*,TextStyle::nsTextFrame&,TextReflowData::nsTextFrame&) [nsTextFrame.cpp:4776]
            nsTextFrame::Reflow(nsIPresContext 
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nsTextFrame.cpp:5014]
            nsLineLayout::ReflowFrame(nsIFrame *,nsIFrame * 
*,UINT&,nsHTMLReflowMetrics *,int&) [nsLineLayout.cpp:955]
            
nsBlockFrame::ReflowInlineFrame(nsBlockReflowState&,nsLineLayout&,nsLineBox 
*,nsIFrame *,BYTE *) [nsBlockFrame.cpp:3459]
            
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState&,nsLineLayout&,nsLineBox 
*,int *,BYTE *,int,int) [nsBlockFrame.cpp:3343]
            nsBlockFrame::DoReflowInlineFramesAuto(nsBlockReflowState&,nsLineBox 
*,int *,BYTE *,int,int) [nsBlockFrame.cpp:3268]
            nsBlockFrame::ReflowInlineFrames(nsBlockReflowState&,nsLineBox *,int 
*,int,int) [nsBlockFrame.cpp:3213]
        Allocation location
            new(UINT)      [new.cpp:23]
            nsAutoTextBuffer::GrowTo(int,int) [nsTextTransformer.cpp:65]
            nsAutoTextBuffer::GrowBy(int,int) [nsTextTransformer.cpp:58]
            nsTextTransformer::ScanPreAsciiData_F(int *,int *) 
[nsTextTransformer.cpp:627]
            nsTextTransformer::GetNextWord(int,int *,int *,int *,int *,int,int) 
[nsTextTransformer.cpp:821]
            nsTextFrame::MeasureText(nsIPresContext *,nsHTMLReflowState 
const&,nsTextTransformer&,nsILineBreaker 
*,TextStyle::nsTextFrame&,TextReflowData::nsTextFrame&) [nsTextFrame.cpp:4381]
            nsTextFrame::Reflow(nsIPresContext 
*,nsHTMLReflowMetrics&,nsHTMLReflowState const&,UINT&) [nsTextFrame.cpp:5014]
            nsLineLayout::ReflowFrame(nsIFrame *,nsIFrame * 
*,UINT&,nsHTMLReflowMetrics *,int&) [nsLineLayout.cpp:955]
            
nsBlockFrame::ReflowInlineFrame(nsBlockReflowState&,nsLineLayout&,nsLineBox 
*,nsIFrame *,BYTE *) [nsBlockFrame.cpp:3459]
            
nsBlockFrame::DoReflowInlineFrames(nsBlockReflowState&,nsLineLayout&,nsLineBox 
*,int *,BYTE *,int,int) [nsBlockFrame.cpp:3343]

Comment 17

[Mike Schuette]

*** Bug 101543 has been marked as a duplicate of this bug. ***

Comment 18

[kinmoz]

Bulk move of mozilla1.0 bugs to mozilla.1.0.1. I will try to pull some of these
back in if I can.

Comment 19

[Malcolm Rowe]

Related to bug 86262?

Comment 20

[rubydoo123]

removing myself from the cc list

Comment 21

[Greg McLearn]

This is occuring in Mozilla 1.0.1 under RH Linux 7.3.  If I paste too much text
into a text field (maybe the size of the text field matters??) then it will
crash not only the browser, but X as well!  Not good.

The URL I am testing is a form system:
http://plg.uwaterloo.ca/~glmclear/kmc.html  (this is a TOTALLY GENERIC FORM
system) I then do the following in a shell window: 

          bash$ i=0; while [ $i -le 1999 ]; do echo -n "0 "; i=$(($i+1)); done

Then I copy and paste it ONCE (X's copy buffer seems to be limited to 4000 chars
-- or maybe it's X's buffer into Moz forms?)  I hit the submit button, and then
the back button. The pasted text disappears.  I paste again, and submit.  X will
crash.  Sometimes it happens on the first time, sometimes on the third time.  It
is absolutely consistent, however.

I have a PIII-700 with 512 MB RAM, running XFree86-4.2.0-8 under Ximian Gnome
and RH 7.3.

Comment 22

[Asa Dotzler [:asa]]

unable to reproduce with 1.7 beta on winXP or FC1. please reopen if you can
reproduce with a current build. see bug 237085 for the blank text entry field
problem.

Comment 23

[AndrewM]

I can reproduce this with the latest nightly on Windows Vista, although it's a hang not a crash. I didn't wait to see how long it would last, I killed the process after about a minute.

Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9a9pre) Gecko/2007101605 Minefield/3.0a9pre ID:2007101605