Closed Bug 504784 Opened 12 years ago Closed 11 years ago

Textarea filled by using this JS hangs the browser

Categories

(Core :: DOM: Editor, defect)

x86
Windows XP
defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: niente0, Unassigned)

References

Details

(Keywords: hang, perf)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; it; rv:1.9.1.1) Gecko/20090715 Firefox/3.5.1 (.NET CLR 3.5.30729)

This javascript script puts some text in a textarea. Google Chrome and Apple Safari execute this script instantly, Internet Explores takes 40 seconds, Firefox hangs.

<html><body>
<form><textarea name="results"></textarea></form>
<script type="text/javascript">
for (i=0;i<1500;i++) document.forms[0].results.value += "\nHello";
</script>
</body></html>

Reproducible: Always

Steps to Reproduce:
1. Copy/past the code in a blank html page
2. Open it in FireFox

Actual Results:  
Browser hangs

Expected Results:  
Show a textarea filled with 1500 "Hello" words

No themes used, plus it happens on all computers
Summary: Textarea filled with this JS hangs the browser → Textarea filled by using this JS hangs the browser
Probably a duplicate of (but variant of) bug 477564.
No, it is not a duplicate of 477564, because the workaround for that bug doesn't work here.
This just highlights our known editor performance issues. See also bug 240933 (proximate cause of the issue here; most of our time is taken up creating all those <br> nodes and removing them, with frame construction costs all the way) and bug 221820 (shouldn't even be using editor here to start with).
Status: UNCONFIRMED → NEW
Component: General → Editor
Depends on: 240933, 221820
Ever confirmed: true
Keywords: perf
Product: Firefox → Core
QA Contact: general → editor
it is similar to Bug 496823 -  to substitute large text into the textarea takes long time(It takes 3 times than before)
Duplicate of this bug: 505566
Depends on: 505730
Depends on: 511812
Attached file faster textarea update
I was able to improve speed by setting display none when modifying textarea 

<html><body>
<form><textarea name="results"></textarea></form>
<script type="text/javascript">
for (i=0;i<7000;i++) {
    document.forms[0].results.style.display='none';
    document.forms[0].results.value += "\nHello";
    document.forms[0].results.style.display='';
}
</script>
</body></html>
Duplicate of this bug: 490075
I believe Olli has some patches that make this particular use case faster in bug 518122.
Depends on: 518122
On trunk the original testcase loads pretty much instantly.

Feel free to reopen if there is still some problem.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
(In reply to comment #10)
> On trunk the original testcase loads pretty much instantly.
> 
> Feel free to reopen if there is still some problem.

Did you try second attachment?
On latest trunk build,it takes much more time to completion loading page than 1.9.2branch build.
As for this, I think that another regression seems to have occurred.

Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100406 Minefield/3.7a4pre ID:20100406040007
(In reply to comment #11)
> (In reply to comment #10)
> > On trunk the original testcase loads pretty much instantly.
> > 
> > Feel free to reopen if there is still some problem.
> 
> Did you try second attachment?
> On latest trunk build,it takes much more time to completion loading page than
> 1.9.2branch build.
> As for this, I think that another regression seems to have occurred.
> 
> Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.3a4pre) Gecko/20100406
> Minefield/3.7a4pre ID:20100406040007

I filed New Bug 557720  - Textarea filled by using this JS hangs the browser
The 2nd testcase is indeed slow, but it isn't the testcase this bug is about.

Thanks for filing the new bug.
This bug hangs my new Firefox v3.6.4, while Bug 557720 (that was purposed as a replacement) has no effect and works perfectly. I think this bug needs to be reopened... and possibly fixed (it's almost one year old).
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
This should be fixed on trunk, not on 1.9.2 branch.
Status: REOPENED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.