343314 - 100% cpu load while typing

Status: RESOLVED DUPLICATE of bug 343659

(Core :: DOM: Editor, defect)

Description

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060630 Minefield/3.0a1 ID:2006063015 [cairo]

This occurs at RANDOM using a latest build

repro:
quickly type text in a textbox

result:
100% cpu load
letters take ages before they are displayed


regressed probably between 20060629 - 20060630

Comment 1

[ignazvonstraubing+bugzilla]

I can confirm this. Also, this only seems to happen when combined with spellchecking, although I may be wrong about this.

Mozilla/5.0 (Windows; U; Windows NT 5.2; en-US; rv:1.9a1) Gecko/20060630 Minefield/3.0a1

Comment 2

[Jonathan Haas]

Can confirm this on Linux, too.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20060601 Minefield/3.0a1 - Build ID: 2006060104

Comment 3

[Bradley Chapman (not reading bugmail, still gone but not forever)]

I can reproduce this on a branch build. Typing takes ~30% CPU, push-and-hold deletion takes ~45-50%.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1a3) Gecko/20060701 BonEcho/2.0a3 ID:2006070104

Comment 4

[Dão Gottwald [:dao]]

(In reply to comment #3)
> I can reproduce this on a branch build. Typing takes ~30% CPU, push-and-hold
> deletion takes ~45-50%.

Unless you have a damn fast CPU, I think that's normal.

Comment 5

[Ryuichi KUBUKI]

(In reply to comment #4)
> (In reply to comment #3)
> > I can reproduce this on a branch build. Typing takes ~30% CPU, push-and-hold
> > deletion takes ~45-50%.
> 
> Unless you have a damn fast CPU, I think that's normal.
> 

Not really. It doesn't happen in this build in my desktop.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060629 Minefield/3.0a1 ID:2006063002

Comment 6

[Dão Gottwald [:dao]]

(In reply to comment #5)
> 
> Not really. It doesn't happen in this build in my desktop.

Then there's probably another regression or it's another indication for the same bug. Becahuse I also see (up to) 30% CPU usage and furthermore 100% from time to time.

Comment 7

[Brad Jackson]

This bug is in my build from CVS that finished on 7/1 at 19:08 CDT.  It is not in the build I did that finished on 7/1 at 7:07 CDT.

Comment 8

[Adam Guthrie]

pkasting, you've been messing with find lately. Can we blame this one on you? ;)

Comment 9

[Adam Guthrie]

Err... disregard my last comment; I misread the bug. This is probably due to spellchecking stuff, actually...

Comment 10

[Haudy Kazemi]

I'm using Mozilla/5.0 (Windows; ; ; en-US; rv:1.8.1a3) Gecko/20060703 BonEcho/2.0a3 ID:2006070303 and have observed the following for several 2.0a3 builds.

I can reproduce this bug fairly frequently on Wikipedia.  It happens most often on large wiki pages that have a lot of text in the editor field.  One example is http://en.wikipedia.org/w/index.php?title=Almond
(If you go there for testing, please don't save testing changes you make.  There's no reason to ruin a good article, or to make extra work for Wikipedians.)

The bug seems to be aggravated by:
1.) having a lot of misspelled words in the editor field (either originally misspelled or freshly mangled or misspelled by you) (it seems that sometimes you need to 'touch' a word for it to spell-check it.) (or you can right click and uncheck 'spell check this field' and then turn it back on again.)

2.) typing really long lines with no whitespace (e.g. make a string of 'z's like zzzzzzzzzzzzzzzzzz, but many many times longer.)  This has several effects:
 a.) cpu usage on this PIII-1.2ghz PC shoots hovers around 98% (watch the process tab of Windows Task Manager) while holding down the repeating key.
 b.) memory usage visibly and continuously rises while the key is being held down. (watch the process tab of Windows Task Manager...enable the mem and peak mem usage columns using the View menu.) I was able to get Bon Echo to go from about 105mb usage to 225mb usage in less than 5 minutes simply by holding down the repeating key.
 c.) this didn't happen every time, but it did happen a few times: initially the Firefox 2 editor field scrolled to the right as expected, but after a while the line of  repeating characters disappears from the UI.  Looking closely, I saw that the vertical scroll bar had gone to the top, while the horizontal scrollbar was still shifting over as a continued to hold down the repeating key.

Comment 11

[Haudy Kazemi]

Attachment: demo text file to paste into a field to show the slowness and high cpu usage bug

Here is a demo text file to paste into a field to show the slowness and high cpu usage bug.  You can even try it locally on bugzilla's comment entry field...just paste it in, then scroll to the bottom of the field and move the text edit cursor over the last dozen lines of text (they're really long single-character repeats).  Soon after you do this, you'll probably find that typing anything else has become noticeably slow and high in cpu usage.  The problem is worst when 'Spell check this field' is enabled (right click over the field to see this option).

Comment 12

[Haudy Kazemi]

I am able to reproduce this on a clean install/clean profile of Mozilla/5.0 (Windows;;; en-US; rv:1.8.1a3) Gecko/20060704 BonEcho/2.0a3.

Also see https://bugzilla.mozilla.org/show_bug.cgi?id=343567

Comment 13

[Brett Wilson]

*** This bug has been marked as a duplicate of 341420 ***

Comment 14

[Peter van der Woude [:Peter6]]

Brett, are you sure this is a dupe of bug 341420 ?

I have set layout.spellcheckDefault 0 
to disable spellchecking altogether and this bug still occurs.

Comment 15

[Brett Wilson]

Then it's probably not a dupe, but it shouldn't have been in the spellchecker component

Comment 16

[Peter Kasting]

There may be multiple different bugs here.

I think some people are reporting bug 341420, bug 339066, and variants (the testcase given seems like a possibility here).  However, for whatever is going on in comment 14, I'm reopening and changing the component to Editor, for lack of something better to stick this in.  More data needed.

Comment 17

[Oakwine]

(In reply to comment #16)
> There may be multiple different bugs here.
> 
> I think some people are reporting bug 341420, bug 339066, and variants (the
> testcase given seems like a possibility here).  However, for whatever is going
> on in comment 14, I'm reopening and changing the component to Editor, for lack
> of something better to stick this in.  More data needed.

See also Bug 343659, reported on Mac OS X with the same regression timeframe.

Comment 18

[Peter Kasting]

OK, bug 343659 has decent steps to reduce and a slightly more clear regression window.  Looks like this isn't a spellchecker issue for sure.  Seems pretty serious so I'm requesting blocking1.8.1.

Comment 19

[Peter Kasting]

Comment on attachment 228009 [details]
demo text file to paste into a field to show the slowness and high cpu usage bug

Obsoleting the testcase given because I think it's showing off the spellchecked slowness bugs, rather than this bug.

Comment 20

[Peter Kasting]

In fact, I'm going to dupe this against 343659, since that's gotten assigned properly and looks like it will make progress.

*** This bug has been marked as a duplicate of 343659 ***