114945 - Text input into the form's input area is slow.

Status: VERIFIED WORKSFORME

(Core :: DOM: Editor, defect, P3)

Description

[Steven Augart]

Visit the above URL.  Start typing into the 
multi-line ``Comments:'' box.

Echoing is really really slow.  I type about 60 words per minute.
If I type a quick sentence -- such as ``The quick brown fox
jumped over the lazy dog'' -- then letters are still being echoed for at least
a second after I've finished typing. 

This does not happen on all multi-line text input boxes.  For example,
the ``description:'' box at http://bugzilla.mozilla.org/enter_bug.cgi
echoes just fine.

For the record, the host is an 800 MHz AMD Athlon Thunderbird, with
512 MB of RAM, lots of which is free, and no other users or other sources
of high load.  It compiles the Linux kernel in about four minutes.
So I don't think this is a processor speed issue.

Comment 1

[Boris Zbarsky [:bzbarsky]]

rjesup, could you profile this one, by any chance?

Comment 2

[Randell Jesup [:jesup] (needinfo me)]

Attachment: jprof of lots of typing in the textarea widget (yes, it was slow)

~61% were hits in/under nsContainerFrame::PaintChild().  Note that this was a
non-realtime jprof, if painting involved lots of X transactions then it could
be even worse in realtime.  PaintChild was called (via various others) from
nsViewManager::Refresh().

90% (incl the above) are within nsEditor::EndUpdateViewBatch().  Most went to
painting, and about 18% (20% of of the 90%) went to
PresShell::ProcessReflowCommand()

Comment 3

[Randell Jesup [:jesup] (needinfo me)]

BTW, I was able to get 10 seconds ahead of the cursor on a dual-450 RH7.1
machine (typing nonsense).  Really bad.  Confirming, adding some editor/perf CC's.

Comment 4

[David Baron :dbaron: (⌚️UTC-5, no longer working on Mozilla)]

It looks like we're repainting the entire page except for the black/white pixel
grid or whatever it is on the right side.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Over to editor:core

Comment 6

[Randell Jesup [:jesup] (needinfo me)]

Attachment: realtime jprof of typing in the widget

Realtime version (much less typing; I crashed once in the stack-crawler trying
to get this, so I only did it for 20 seconds or so).  Of the non-poll hits,
again the time spent is similar, - around 2/3's in Paint.

Comment 7

[Mike Schuette]

I'm seeing this too on Win98SE 2002013103 ... OS All?

I swapped 2 vidcards & updated every driver I could find before I found this bug :)

I noticed this first in a hotmail "Compose Message".  It's significantly slower
on hotmail than it is on the reference URL.  Chars appeared at about 5-8/sec on
hotmail, while the reference URL's delay is barely noticeable, although
definitely noticeable when looking for it.

Interestingly, I can't seem to get any delay out of this textarea in bugzilla,
even when thrashing the keyboard for junk characters.  I'll try to find a
testcase in the near future.

500Mhz Celeron, 192 ram (all of it free, reboot & launch moz).  Tried a Number
Nine card & i740-based card, both AGP.  (Old hardware is free hardware.)

Comment 8

[Daniel J. Peng]

Works for me on a PII-300 running Mozilla 0.9.8 on Mandrake Linux 8.0, though
Bug #123623 (Form text input is slow) gives me problems. 

Comment 9

[Kevin McCluskey (gone)]

Marking nsbeta1+

Comment 10

[Steven Augart]

In response to Daniel Peng's comment
(http://bugzilla.mozilla.org/show_bug.cgi?id=114945#c8), I tried the
test case again both with Mozilla 0.9.8 and with Mozilla 0.9.5, the browser
I wasw running when I reported it.  

I can't re-create the problem any more either.  Text input is echoed at my
maximum typing speed.

I hypothesize that techrepublic.com probably changed the HTML generating that
form input area in some subtle fashion that affects Mozilla's update speed.

So the bug's still there in Mozilla somewhere; this just is no longer a
good test case for manifesting it.

Comment 11

[Kevin McCluskey (gone)]

Works fine using 2002031803 build on WinXP. 750Mhz processor. 

Comment 12

[Kevin McCluskey (gone)]

Resolving WFM.

Comment 13

[sujay]

marking verified...Steve, REOPEN if its still not working for you..

thanks.

Comment 14

[Steven Augart]

Sujay, do you mean that I should only whine if it's not fixed in a build dated
3/18 or later?  I happen to be running released builds right now but am willing
to update my CVS tree and rebuild or download a daily if it would be helpful.

--Steve Augart

Comment 15

[sujay]

Steve, yes, let us know if it is not working....verify in a
build later than when this fix went in...hope this helps.

Comment 16

[Steven Augart]

Sujay: I have verified that the problem does not recur.  Clean with 0.9.8,
0.9.9, and daily build of 2002-Mar-29.  However, the bug reported by Daniel Peng
(<a href="http://bugzilla.mozilla.org/show_bug.cgi?id=123623">Bug # 123623</a>)
is still manifesting itself, even with the 2002-Mar-29 daily.
Thanks, --Steve