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

VERIFIED WORKSFORME

Status

enhancement
VERIFIED WORKSFORME
18 years ago
15 years ago

People

(Reporter: Peter, Assigned: sspitzer)

Tracking

({perf})

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

Reporter

Description

18 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

18 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.
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

18 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).
Reporter

Comment 4

18 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

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

Comment 6

18 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

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

Comment 9

18 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: 18 years ago
Resolution: --- → WORKSFORME

Comment 10

18 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.