6/7 13 branch win32 I'm not sure when this started, it was a while ago. It seems to keep getting worse! Create a new compose window Wait around to type your address Complete any autocompletion so you don't hit the bug where tab selects addresses Hit tab once or twice depending on whether you'd like to wait to enter the subject or the body Start typing Wait for any characters to show up I can generally type 2 tabs and Jean-Francois, Why so slow? before seeing any text in the message body.

We should look at whether there's an obvious fix for this before RTM that could go in a limbo build. There is a build back in m.9 that is not as bad as current builds. It may be that finding the day this regressed so bad would help figure out the cause. I remember thinking that the time it takes to draw focus outlines for the subject line might be related. Perhaps that can help bound the time period where this changed.

I can see two things that could be the cause: 1) The new autocomplete widget 2) LDAP autocomplete Steve, are you using LDAP?

change->stephend

Yes, this has been really bad, I also see this when typing the @ character, it hangs for a second or so (no LDAP here), this is slower than normal for me, too.

cc'ing hewitt

putting into 0.9.2

Everytime I set the focus in one of the addressing widget edit field, the user is blocked for about 1-2 seconds!!

reassign to varada

moving to 0.9.3.

Is anyone still seeing this? I haven't seen this for a while.

Scott, Varada and I looked at this on my machine, and I'm no longer seeing it with the trunk builds on Win2K.

Here's another possible clue. Between all address inputs the chrome flashes. My guess would be command updaters are doing something. It's interesting that I'm inputting addresses but the spell checker icon will blink even though it's disabled. Is it possible we're cycling it from disabled to enabled and back in between address inputs?

Yes, selmer is correct: we're needlessly updating a whole bunch of commands every time *anything* takes focus in the msg compose window, even if you're not touching the msg body. I'm working on a fix for that. Meanwhile, I have a fix that makes focusing the body instanteous after the first time (and speeds up the first time). It's pretty simple, if this is still being considered for branch...

The general perf suckiness when tabbing between widgets in message compose is now bug 89624. It sounds like some people were having especially bad problems tabbing from the address widget, so I'm leaving this bug open for now.

Doesn't look like this is getting fixed before the freeze tonight. Pushing out a milestone. Please correct if I'm mistaken.

--> me

Steve, my patch in bug 89624 should have improved this and window opening time significantly. I am still seeing a problem where, in certain cases, it takes a long time to show the caret in the message body (although you can type), the first time you focus it. Subsquent times are instant though. Please test and let me know the results, thanks. *** This bug has been marked as a duplicate of 89624 ***

verified dup. Blake has purposely left open bug 89624 to address future optimizations. As it stands this has improved tremendously. Thanks, Blake.