306594 - Editing a large amount of bidirectional text in textarea is horribly slow

Status: RESOLVED WORKSFORME

(Core :: Layout: Text and Fonts, defect)

Description

[Joona Palaste]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.10) Gecko/20050720 Fedora/1.0.6-1.1.fc3 Firefox/1.0.6

I just tried to use the URL given in the URL field to modify the contents of the
Wikipedia Reference Desk for language. To my surprise, editing the text in the
textarea had suddenly become horribly slow. Every keystroke seemed to take over
a second to appear, and caused the CPU usage to jump to 100%.
This is now 100% reproducable on my computer. This only happens when editing
very large pages such as the 73-kilobyte Reference Desk. Editing smaller pages
(only a couple of kilobytes) works OK.
The weird thing is, I used to be able to edit large pages (even well over 200
kilobytes) just fine only yesterday. Now this problem has suddenly appeared and
even a reboot doesn't help. I have not installed a new version of Firefox or any
patches.


Reproducible: Always

Steps to Reproduce:
1. Go to the URL given in the URL field.
2. Type some text in the text area.


Actual Results:  
The CPU usage jumps to 100% and the typing appears at about one second per
character.

Expected Results:  
The CPU usage should have stayed at less than 50% and the typing should have
appeared as soon as I typed it.

Comment 1

[Joona Palaste]

I seem to have found the problem myself. That particular 74-kilobyte text
contains Arabic, Hebrew and other non-Latin-script characters as literal glyphs,
not as HTML escape codes. Editing the Science Reference Desk, which is over 20
kilobytes longer, but completely Latin-script-only, works all OK. So the problem
is instead that editing text containing literal non-Latin-script glyphs is too slow.

Comment 2

[Uri Bernstein]

Notice similar bug 188294 (which is, at least currently, Mac-specific).

Comment 3

[Simon Montagu :smontagu]

We need some kind of profiling info to go anywhere with this.

Comment 4

[Boris Zbarsky [:bzbarsky]]

The wikipedia page now has HTML escapes as far as I can tell... is there a testcase for this bug?

Comment 5

[Shoshannah Forbes]

(In reply to comment #4)
> The wikipedia page now has HTML escapes as far as I can tell... is there a
> testcase for this bug?

Any large Hebrew wikipedia page will do. 
Random example:
http://he.wikipedia.org/w/index.php?title=תרנגול_כפרות_%28ספר%29&action=edit

(I'm on OSX at the moment, so I'm seeing bug #188294)

Comment 6

[Boris Zbarsky [:bzbarsky]]

On the page in comment 5, I see nothing even close to "one character per second" performance.  In fact, typing performs better than on some English-only articles (eg http://en.wikipedia.org/w/index.php?title=History_of_the_Jews_in_Poland&action=edit).

This is all with a current trunk Seamonkey GTK1 build.

Comment 7

[Uri Bernstein]

(In reply to comment #6)
> On the page in comment 5, I see nothing even close to "one character per
> second" performance.  In fact, typing performs better than on some English-only
> articles (eg
> http://en.wikipedia.org/w/index.php?title=History_of_the_Jews_in_Poland&action=edit).
> 
> This is all with a current trunk Seamonkey GTK1 build.
> 

For me, the Hebrew page (comment #5) is significantly slower than the English one (comment #6). It might not be 1 char per second, but it's probably not more than 2 per second.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051214 Firefox/1.6a1

Comment 8

[Shoshannah Forbes]

(In reply to comment #7)

> Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20051214
> Firefox/1.6a1

you are on Mac, and therefore seeing bug #188294, which results from the way Hebrew text is used in Gecko-Mac.

The question here is- do we have another problem with Hebrew text in addition to what is seen in bug #188294, which affects all platfroms and not just Mac?

Comment 9

[John Vandenberg]

I am not seeing this on Firefox 2.0 / Windows XP.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Comment 10

[Boris Zbarsky [:bzbarsky]]

This has been worksforme for me all along; given that it's reported against Gecko 1.7 and all the perf work since then, I'm resolving it so...  Reporter, please reopen if you still see the problem with a current trunk build?