Closed Bug 188294 Opened 17 years ago Closed 13 years ago

Extremly slow editing a large amount of mixed Hebrew/English text in a textarea


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

Not set





(Reporter: xslf, Assigned: mkaply)




(Keywords: helpwanted, intl)


(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030101
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X; en-US; rv:1.3b) Gecko/20030101

When attempting to edit large text in a text area- for example, when replaying
to a forum with a quote or editing text in a wiki, the editing is extremply
slow- it litrerly texts a few seconds since I type a character until it appears
on screen. It is so slow it is unusable.

This does not happen in English only pages/forms

Reproducible: Always

Steps to Reproduce:
1. Try to edit a form with lots of mixed text. For example this wiki page: or a post in a message
board with quote of a previos user:

Actual Results:  
Editing is painfully slow

Expected Results:  
Should edit in the same speed as English sites
Severity: normal → major
Blocks: 190306
*** Bug 190306 has been marked as a duplicate of this bug. ***
This is getting slower every build, and makes blogging / editing wikis / writing
email / editing web pages with composer basiclly impossible.

any progress here?

Just see how slow this example is:
Blocks: 152111
sfraser: would you be able please to take a look at this? I saw you where
working on similar bugs, and this one is a major one for Hebrew/Arabic users.

In addition, CPU usage is more then 95%, when viewing a RTL contained Page, 
Or, when trying to edit Hebrew text fields.
Sorry, I'm not working on Mozilla much any more.
Depends on: 212827
--> bzbarsky: can you please help?
Not really -- I'm not exactly familiar with the bidi code.  Once bug 212827
lands, I'll probably try profiling this; until that point it would just be a
waste of time.
Yeah, but 212826 seems to have helped.  The page almost keeps up with my typing...

Total hit count: 1462
Count %Total  Function Name
 47   3.2    
 40   2.7     uMapCode
 40   2.7     SearchTable
 33   2.3     _ZN12nsLineLayout11ReflowFrameEP8nsIFrameRjP19nsHTMLReflowMetricsRi
 32   2.2    
 26   1.8     _ZNK15nsBidiPresUtils17CalculateCharTypeERiiS0_S0_S0_RhS1_
 25   1.7     _ZN14nsStyleContext12GetStyleDataE15nsStyleStructID
 24   1.6     _end

is the top of the flat profile; about 1/7 of the total time is spent in
nsBidiPresUtils::Resolve (202 of the 1462 total hits).

Shoshannah, could you retest and see how it looks for you now?
I tested with the page
and didn't see a noticible diffrents (build id 2003073003)

How do I get the hit count?
The slowness is worse as the amount of text in the text box is larger. When you
try to edit this page,
on G4 500 MHz, each letter you type causes few seconds delay and a spinning
beach ball. This is not painfully slow, it is not usable at all.

Note that on the much slower hardware - G3 266 MHz, running Linux PPC, Mozilla
runs just fine. It is not fast as Konqueror in typing, but its ok.

When you profile Mozilla, you should use different text size, because using
small texts does not show the problem. We need here 1000% improvment.
To see the problem, click the link below and try to edit the textarea.

Note that although usable, this is also quite slow on an 850MHz PC with WinXP Pro.
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925

With IE6 I get immediate feedback and typing is fluent, but with Mozilla (Win32)
there's a noticeable delay, making it difficult to type fast.

The attached testcase demonstrates that this unusably-slow behavior also
happens on Mozilla/Win, it does however kick in with smaller texts on Macs.

Someone else with access to both platforms would like to test this and comment
on whether this bug is really for All Hardware and OS?

I was attepting to update a few articles today in the Hebrew wikipedia ( ): it 
is just unworkable.
Your testcase is the same. I get a few seconds (!) delay between when I type a character until it is 

I am on osx 10.3.2
I checked this testcase under 1.7a/BeOS and it was completely unusable, on the
other hand the wiki page was  reasonably editable. Let's leave this as Mac-only
for now.

Blocks: 103669
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040206 Firefox/0.8

As comment #15 also stated, I have no problem editing the textarea at the Wiki,
but trying to edit text on the testcase is extremely slow.
I believe OS should be changed to all, i'm on win2k at the moment.

By the way, this is my first message in bugzilla, I apologize if I missed
something :)
Blocks: 240501
It looks as a result of our behavior on mac when rendering using ATSUI APIs (For
Hebrew and Arabic, we are always using ATSUI).

Quoting from
"because the Mac QuickDraw BIDI support are quite different from other platform
we try not to use them and use the XP BIDI feature those text will be drawn by
*ATSUI intead one character at a time*"

The problems with "ATSUI intead one character at a time" are mentioned here:
bug 120401 comment 122
bug 121540 comment 113

Fixing "one character at a time" behavior is discussed in bug 157967.
Depends on: 157967
Keywords: helpwanted, intl
QA Contact: zach → bugs.mano
Depends on: atsui
FWIW: this bug also affects email coposition and web page editing (in Thudnerbird and N|vu as well as in Seamonkey) very badly. It seems that bug #121540 and bug #157967 are going for long-term solutions (FF2 and beyond, using Cairo...), I wonder if there is any way to have a stopgap solution for here, so us Mac users are not left with major parts of functionality in the current web broken, as it is right now?
Do the latest text rendering changes for FF3 affect this?
Uri- didn't you work on some related issues?
(In reply to comment #19)
> Do the latest text rendering changes for FF3 affect this?
> Uri- didn't you work on some related issues?

I'm not sure which changes you're referring to. Cairo/Mac is still not built by default, and I haven't been able to test it.

I didn't work on any Mac-specific text rendering issues. It's possible that fixing bug 319930 and bug 329878 (which are not Mac-specific) had some effect on this, but the attached testcase is still extremely slow on latest trunk builds.
This seems to be fixed by the Cairo landing (bug 323934) - editing of the Wikipedia entry mentioned in comment #10 is now completely fluent for me, and even the attached testcase is much, much faster than it used to be.

Shoshannah, could you please verify?
Closed: 13 years ago
Depends on: 323934
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9alpha
Component: Layout: BiDi Hebrew & Arabic → Layout: Text
QA Contact: mano → layout.fonts-and-text
You need to log in before you can comment on or make changes to this bug.