Closed Bug 182150 Opened 22 years ago Closed 18 years ago

Typing is unusably slow in mail main and composition windows (Mac OS Shared Menus)

Categories

(MailNews Core :: Composition, defect)

Product:
MailNews Core
Component:
Composition
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
critical

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: jds, Assigned: bugzilla)

Details

(Keywords: perf) 

User-Agent:       Mozilla/4.0 (compatible; MSIE 5.22; Mac_PowerPC)
Build Identifier: Slow typing in mail composition window

The slow typing probem appeared with 1.2b, but is not present in 1.2a (works fine).  This 
should help zero in. 


Reproducible: Always

Steps to Reproduce:
1.  Open message composition window (click on Compose in Mail client)
2.  Type in body of message composition window

Actual Results:  
Notice glacially slow typing, roughly one character per second.  
This is observed every time in 1.2b and 1.2 (release)

Expected Results:  
Normal behavior is seen using 1.2a, ie, typing takes place about as fast as I can type on 
the same computer system and OS.  

Is it possible that a type-ahead feature is somehow eating up CPU cycles?  

System info: 
Mac OS X version 10.2-10.2.2 (haven't tested 10.1.x). 
500MHz G3 Pismo (Powerbook G3 Firewire)

Note: may be related to bug 172053:
http://bugzilla.mozilla.org/show_bug.cgi?id=172053

But confirmed by friends on Mac.  We are using 1.2a until this is fixed.
WorksForMe using FizzillaMach/2002112507. Jim, can you reproduce this problem
using another Mozilla user profile?
Keywords: perf
Problem persists, even in a new profile with fresh mail folders (and the default
"classic" theme, as opposed to my usual "modern" theme).  

Since not all users reproduce this, it may have to do with the computer clock
speed, memory issues, disk fragmentation, etc.  My system is a G3/500 Pismo
Powerbook Firewire with 640MB RAM and 4.4GB free disk space (fragmented).

Any advice on how to test this further?  Can anyone else reproduce this?  

Bug is serious enough to cause myself and a friend also testing this to stay
with 1.2a.  
Changed Summary to reflect the following: 
- Confirmed bug still present in 1.2.1. 
- Confirmed that slow typing is present in all mail fields, including password
dialog, name or subject contains, to, subject, and body.  

1.2a is free of this bug.  It is very serious for those stricken with it. 
Contact me if I can test something for you!  --Jim S.
Summary: Typing in 1.2b and 1.2 is unusably slow in mail composition window → Typing is unusably slow in mail main and composition windows
Jim, please also try a current nightly trunk (1.3 pre-alpha) build.
Tested nightly build of 1.3a 12/4/02, and problem was still present.  

However, I have narrowed down the problem -- it only appears when I use a
"shared menu."  Version 1.2b was the first to have a form of shared menu
support.  This was also the first build that showed the problem.  I use URL
Manager Pro as a bookmark manager, and use its shared menu capability to show a
single menubar menu of bookmarks when in Mozilla.  My friends who also observed
the slow typing are also using it.  

Disabling shared menus in URL Manager Pro's preferences and relaunching Mozilla
eliminated the typing delay.  I will make sure that Alco Bloom (author of URL
Manager Pro) knows of this.  But, I am not convinced there is anything wrong
with URL Manager Pro... it works superbly with Internet Explorer.  I will also
poll the UMP beta tester and user email list.  

Whoever is most familiar with the Mozilla implmenetation of shared menus can
contact me, and should contact Alco Bloom, who no doubt will happily assist.  

Are there other apps that utilize shared menus?  If so, can someone test them
for the slow typing problem?
cc'ing sfraser in case he has a clue...
I have further found that the speed of typing is slower when there are a larger
number of bookmarks in the URL Manager Pro document that is being shared via
shared menus support.  Although I'm sure there is a reason for this, it won't be
a deliberate one....  The UMP document is not even accessed, or at least should
not be accessed, unless and until the shared menu is clicked.  Perhaps there is
some unnecessary activity, or perhaps a memory problem?  

Looks like we need to add a new keyword to the dictionary for "shared menus."
Summary: Typing is unusably slow in mail main and composition windows → Typing is unusably slow in mail main and composition windows (Shared menus)
Due to Mozilla's constant switching between different menu bars Alco added code
to the shared menu component to check on every call to CheckSharedMenus() to see
if the shared menus are installed in the current menu bar.  This isn't supposed
to have much additional overhead if the menu already exists but perhaps it does.
 What version of the SharedMenus.component do you have installed?
Thanks, Steve.  I was using SharedMenus.component v1.2.2.  I just now downloaded
v1.2.3, the lastest that I know of, and found that the slow typing was much
improved but not up to normal speed (without the SharedMenus.component active).
 It is fast enough to be useable, but slow enough that I can easily out-type it,
giving a poor "user experience."  This, on a G3/500 with 640MB and 10.2.2.  

I'll make sure Alco gets this update.  Is it your thinking, Steve, that Alco is
the only one who can speed this up?  
I haven't had a chance to write Alco about it myself but I hope he can do some
optimization in the code called by CheckSharedMenus().  The brute force approach
I can see as an alternative is to not call CheckSharedMenus() on every idle. 
I'll cogitate more after I get some sleep (today started waaaaay too early for
me :-)
Status: UNCONFIRMED → NEW
Ever confirmed: true
I have to retract what I said about SharedMenus.component 1.2.3 being an
improvement.  At some moments, it is just as bad as v1.2.2.  

There seems to be some variability whether I see a large slowdown or a small
one.  I'm not sure why the speed varies, whether it has something to do with
other processes running, or memory usage.  It could be processes running in my
system, like TypeIt4Me (which is installed but "off" at the moment, yet the
typing is still slow).  Some of the others I use are PTHPasteboard, Diablotin,
PowerChute, APE Manager, FruitMenu, Tinkertool.  
After reading this bug report, I can confirm that moving the URL Manager Pro
Shared Menus Component out of ~/Library/Components thereby disabling it, brings
the speed of typing to what I would expect. Before, typing was at the rate of
approximately one character every 1-2 seconds... glacial. This slowdown was also
present in the window activated by Shared Menu to add a bookmark. I have well
north of a thousand bookmarks, so Jim and I have that in common. I don't have
any of the other apps mentioned by him except TinkerTool. I'm going to check
with 'ps aux' whether there is a difference in CPU or memory usage to help
narrow this down. The only other thing that may make a difference is I'm on an
iBook which is also a G3. Is anybody on a G4 noticing this problem or is that
definitely a red herring?

It's definitely a CPU thing. using 'top' I can watch the CPU usage for mozilla
spike to 90% the minute I start typing with the Shared Menus Component enabled.
When I'm typing with it disabled, it doesn't go above 30%.
OS: MacOS X → All
Hardware: Macintosh → All
Because this bug also appears in windows , solaris  too, so changed to all OS
Severity: major → critical
I am not sure if this is what I am seeing with 200301071 trunk build for MacOS9.x..
Any typing, whether in Mail, Composer, URL bar, or textarea of a form, is
extremely slow and Mozilla misses input if typed too fast. 
This bug is specifically about URL Manager Pro's Shared Menus component making
typing slow; it therefore cannot be cross-platform.
OS: All → MacOS X
Hardware: All → Macintosh
Do shared menus get installed by default with 1.2.1 for Windows?  I'm running
Windows 2000 and stumbled across this bug because I was checking to see if
anyone else is having trouble with slow typing in Mail composition window.  How
can I check to see if the shared menu components are in my components folder? 
In the event I'm way off base here, are you aware of any other bugs of this type
on which I can provide feedback?  I did the simple search on keywords slow and
mail and this bug was the best fit for my problem.  Thanks!
Shared menus are a Mac-only thing.
Summary: Typing is unusably slow in mail main and composition windows (Shared menus) → Typing is unusably slow in mail main and composition windows (Mac OS Shared Menus)
Here it's also quite slow (just a little bit slower than my typing speed), but
no characters are lost. In WinXP/dual Celeron 333/512MB (1.2.1/2003012508) it's
slow, but in Win98/Celeron333/128MB (1.2.1) it works fine. Tried tweaking the
performance options in WinXP, but nothing helped. (could be the existence of an
Alpha layer in the GUI?)

The editor used is the Mozilla Editor (www.mozilla.org/editor says so), and I
disabled 'compose in HTML format' for this account. Why is it so much slower
than the embedded editor (the one I'm typing this in)?
I am seeing this in the nightly build (2003060808) on Windows 2000.  It is
*really* bad.  It's so slow that the composer is barely usuable.

Is someone working on a fix??  Please fix this...

Also, not to distract from the importance of fixing this one, is bug #172053 a
duplicate?

Can someone please update the Hardware and OS fields because this problem occurs
on Windows 2000 on a PC too.

This is a really major bug.  It happends very frequently but not always but when
it does, it is very painful.  If you want to type a message, there is a full one
second between e-a-c-h  a-n-d  e-v-e-r-y character typed.  I think you get the idea.

PLEASE PLEASE FIX THIS.
Periodic reminder for folks that can't read - the problem described in this bug
is specific to a Mac OS X _ONLY_ feature.  If you think typing is slow on
Windows, FILE A DIFFERENT BUG
Anyone who wishes to comment on slow typing in Windows 2000, Windows XP, Solaris
and other platforms should refer to this bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=218975


p.s.

[attitude autorelease]; // ;-)
Product: MailNews → Core
This bug has been dormant for 30 months -- is it still a problem?
If not, please mark it:   Resolved | WorksForMe
hardly seems it could be "critical" (if the problem exists) given the lack of response.
Agreed.  => WFM -- reporters, feel free to reopen if the problem has not in 
fact disappeared.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.