Tabbing in address fields of message composer has "sluggish" response (makes app seem unresponsive)

VERIFIED WORKSFORME

Status

SeaMonkey
MailNews: Message Display
--
enhancement
VERIFIED WORKSFORME
17 years ago
14 years ago

People

(Reporter: Peter Lairo, Assigned: (not reading, please use seth@sspitzer.org instead))

Tracking

({perf})

Trunk
x86
Windows NT

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

17 years ago
Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1+) Gecko/20010629

Tabbing in address fields of message composer has "sluggish" response (makes app
seem unresponsive).

Se also bug 87307 for a similar "sluggishness" issue.
(Reporter)

Comment 1

17 years ago
adding keywords to match other "sluggishness bugs (bug 87307 and bug 49141).

This issue is after typing an address and going to the next blank address line -
it takes a while before the curser reappears. Also tabbing between addresses,
subject and body there seems to be a noticeable and disturbing delay.
Keywords: 4xp, mail1, mozilla0.9.3, nsCatFood, perf, topperf
Tabbing between address fields is not at all sluggish for me. Tabbing (or
clicking with mouse) to the addresses (from subject/body) or subject looks
sluggish though, because the cursor appears later than it should, i.e. you can
type in the field .5s before the cursor appears. In other words, it's not slow,
it just chooses to look slow.

Comment 3

17 years ago
clearing all keywords (except perf)
using build 2001070108 win32 I don't find it sluggish at all.

Could you try increasing your cursor blink rate to the maximum in your control
panel keyboard control? Make sure you do it before Mozilla starts. See if it is
still sluggish. This is just to test if it really is a performance problem or a
cursor blink timing problem (I've heard of the cursor blink timing problem
before, but I don't remember the bug number and I'm having trouble finding it).
Keywords: 4xp, mail1, mozilla0.9.3, nsCatFood, topperf
(Reporter)

Comment 4

17 years ago
It's not a curser timing problem. The curser blink rate is much faster than the
time it takes for the curser to appear after tabbing to the next/new address
line. There is about a 0.5 sec delay of when the curser "should" be visible.

Reinserting keywords because they are valid. Basic, you are not the assignee or
the reporter. Please don't mess with my keywords.
Keywords: 4xp, mail1, mozilla0.9.3

Comment 5

17 years ago
Spamming your bugs with keywords doesn't fix them.  Actually, since you add them
practically everywhere, they become useless.

Comment 6

17 years ago
PLairo: if you insist, but actually QA's are allowed to remove keywords, I'll
let you keep your keywords except "mail1" as that should only be used by
mail&news Developers/QAs.
Keywords: mail1
Caret timing problems in bug 59546 (its summary is a bit dated). On win98, the
delay in the appearance of the caret is always half the blink cycle.

Comment 8

17 years ago
Hopefully, Blake's patch in bug 89624 will fix this problem.
Depends on: 89624

Comment 9

17 years ago
worksforme with 0.9.4 mozilla branch builds on win2k. No sluggish behavior. I
hit enter after typing an address and the next field has the cursor instantaneously.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → WORKSFORME

Comment 10

17 years ago
Works fine for me, too, with 0.9.4 sep19 commercial build, win98. 
Status: RESOLVED → VERIFIED
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.