Closed Bug 152356 Opened 23 years ago Closed 22 years ago

text fields slow to render typed or deleted characters

Categories

(SeaMonkey :: Location Bar, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 158782

People

(Reporter: m_mozilla, Assigned: hewitt)

References

Details

(Keywords: perf, polish)

when I type at normal speed (fast) in the URLbar, the cursor moves forward with each character typed, but there is white space instead of the typed characters for a noticable amount of time. For example, if I type "this is a test", the first 't' will render, then there will be whitespace as the cursor moves forward, and right around when I've typed the 's' in 'test', the whitespace turns into 'his is a tes' and then I type the last 't' and I see the cursor advance, then the whitespace turn into the last 't'. Similarlly, if I delete, the cursor moves left over 'this is a test', but the characters are still rendered to the right of the cursor for a noticeable period of time. The get "unrendered" in about three blocks if I'm holding the delete key down (probably varies depending on your key-repeat settings or some such). Hmmm... URLbar may not be the appropriate component for this. I'm also seeing it in this textarea as I type this bug. However, it's *much* worse in the URLbar. Here in the textarea, I can only get the cursor to get the rendering to fall one character behind. This is MacOS X trunk build 2002061603. The last build I had downloaded before was (I think) MacOS X trunk build 2002061208 (or maybe 2002061308). I did not notice this issue in that build. It is difficult to re-train the eye to follow the cursor to know when to stop deleting, because the eye is used to following the shrinking text. This can cause users to delete more text than they intended. Similarlly, it's annoying not having the feedback as you type, because if you mistype, you don't know right away, and type a few extra characters that you then have to delete over to get back to where you made the error. Users are just plain used to having their keyboard input give them feedback immediately (at least when that keyboard input is plain old typing). -matt
Blocks: 91351
Keywords: perf
I didn't start seeing this until after bug 141900 was fixed. I'm on Win2K. cc: Kin
This bug is a big usability/regression problem. Mac8.6 Mozilla 1.1b Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.1b) Gecko/2002073003
I agree. If Mozilla is busy doing something, like loading a page, and I start typing, I can have the entire url entered and press enter without a single character displaying.
btw every text field are affected by this bug.
Yes, I meant to mention that. It's most evident in the url bar, but I've hit the behavior I described in comment 3 in form text fields as well. Changing summary and adding some keywords to try and get this some attention. Also changing platform/os to all/all, since I see this on Win2K.
OS: MacOS X → All
Hardware: Macintosh → All
Summary: urlbar slow to render typed or deleted characters → text fields slow to render typed or deleted characters
Missed mozilla1.1. Trying for mozilla1.2.
Keywords: mozilla1.1mozilla1.2
It's now worksforme here in the URL bar, text and textarea fields. Mozilla 1.2b Mozilla/5.0 (Macintosh; U; PPC; en-US; rv:1.2b) Gecko/20021018 Mac8.6
This bug has been temporarily fixed on the TRUNK with the checkin of attachment 101640 [details] [diff] [review] from bug 141900 during the mozilla1.2beta milestone. It basically disables the code which landed as part of attachment 87307 [details] [diff] [review] (async reflow and painting for text widgets) until all issues blocking bug 174823 can be resolved. *** This bug has been marked as a duplicate of 158782 ***
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.