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)
SeaMonkey
Location Bar
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
Updated•23 years ago
|
Comment 1•23 years ago
|
||
I didn't start seeing this until after bug 141900 was fixed. I'm on Win2K.
cc: Kin
Comment 2•23 years ago
|
||
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
Comment 3•23 years ago
|
||
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.
Comment 4•23 years ago
|
||
btw every text field are affected by this bug.
Comment 5•23 years ago
|
||
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
Comment 7•22 years ago
|
||
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
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•