(spellchecker-related)Textarea poor performance with very long strings

RESOLVED WORKSFORME

Status

()

Core
Spelling checker
--
minor
RESOLVED WORKSFORME
7 years ago
7 years ago

People

(Reporter: David Turover, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

7 years ago
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

Firefox consumes 100% CPU after putting a very long unbroken string in a text box and trying to edit it. Turning off the spell checker fixes this.

Reproducible: Always

Steps to Reproduce:
1. Copy and paste a 1MB unbroken string into a text box.
2. Delete a character off the end.

Actual Results:  
Firefox hangs for several seconds, consuming 100% CPU for the time. On repetition, the hangs last for increasing minutes until I force-quit Firefox. On restarting, Firefox hangs for at least 15 minutes attempting to render the recovered page.

Expected Results:  
Firefox shouldn't hang the entire browser, at least not for that long. 

After turning off the spelling checker, it takes only one second on a 2GHz cpu to delete a character under the described circumstances and the delay does not increase with repetition. The spell checker has an UNREASONABLE_WORD_LENGTH constant which should halt processing fairly quickly, but apparently some unneeded processing of the large string is still happening either before or after that is used.

Slowdown initially seen in 3.6 and still exists in FF4 RC1. Disabling plugins had no effect. This may or may not be related to Bug 496360 or Bug 596507.

Updated

7 years ago
Component: General → Spelling checker
Product: Firefox → Core
QA Contact: general → spelling-checker
Version: unspecified → Trunk
Created attachment 519193 [details]
testcase - a 1.35MB text file

Comment 2

7 years ago
I can't reproduce this.  For me, the operation is kind of instant!

I'm testing this on data:text/html,<textarea>.  Are you seeing this problem on a particular web page?
(Reporter)

Comment 3

7 years ago
In 4.0 release, I can not reproduce the problem anymore so I will close it as WORKSFORME. I wonder what changed that might have affected this; I don't see anything obvious in the recently fixed bug list.

To answer comment #2's question, I saw this problem on:
http://www.opinionatedgeek.com/dotnet/tools/base64decode/

I do not remember where I originally got the huge string.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → WORKSFORME

Comment 4

7 years ago
One of the things which might have helped here is bug 240933.
You need to log in before you can comment on or make changes to this bug.