I am using Friday morning's build. Conincidentally this has the new UI too. I read a thread where the urlbar was slow because of the UI design. I see all text fields slow to the point of being unusable.

I meant all text form fields like the this bugzilla comments. Marking dogfood.

It is at least fast enough to keep up with my keyboard repeat rate on a 650 MHz Athlon. Linux build 2000-08-26-08.

sujay, can you see if this is specific to the new modern. Are we as slow in classic or blue?

I see a huge difference between URL location bar speed and form input tags. It seems to be not just the text field. For example the "Add CC" is much faster then "URL" in typing on bugzilla under mozilla. Does anyone else notices that? For me, I've always noticed this problem, but as mozilla has gotten faster, this stands out more.

assigning this to kin for review -- reassign as necessary

it has gotten substantially better with the latest (as of this writting) build. Perhaps this is skin related? (or autocomplete lookups?) There is certainly some room for improvement, as I can easily type faster then it, and sometimes it stalls... Is there a way to turn off autocomplete lookups to see if it is the culprit?

Accepting bug ... though the cause of the slowdown reported in this bug (a regression) was actually caused by the images used in the new modern skin toolbar ... this has been fixed already which is why caught@prodigy.net noticed a speedup. Typing in general is still kind of slow (though not as slow as during the new modern skin landing), so I'm not sure if I'm supposed to mark this bug fixed or keep it open? PDT?

With the fix to the modern skin, text fields aren't too bad in my build; but anything multiline (multiline textareas, or the composer window) are so painfully slow that it stops me from using it. This happened sometime between 8/4 (when typing performance was fine) and 8/14.

Hmmmmm, typing in a textarea is significantly faster in viewer than in Mozilla. Perhaps the difference in speed is caused by JS listeners/controllers used in Mozilla?

Thanks to akkana for thinking out loud on IRC about XULKeyListenerImpl::HandleEventUsingKeyset() ... stubbing out this method significantly improves typing speed!!! A rewrite is planned for this method. (Bug #47395) Making this bug dependent on that one.

this is the same on macOS, but probably to a slightly lesser extent. Some fields are fast (url bar, for one), others are middle of the road, others, like the field I'm typing in right now, are pretty slow (G4 450).

my bug, baby

Adding myself to Cc list.

I don't understand where this is still dogfood for Linux or Windows, since it keeps up with my fastest typing easily. I've gotten into modes where it was 2 CPS, but the general case seems plenty fast.

hyatt submitted code last night to make xbl key handling much faster (see news://news.netscape.com/39AF65F2.66DECFFC%40netscape.com), which should make this bug not an issue for dogfood. since the original symptoms for this particular bug were caused by new modern slowness (also fixed), this should not be related to 47395 as it is. also, my cvs pull from this morning is (comparatively speaking) ridiculously fast. i'll keep this bug open for tracking, and leave it dependent on 47395. i know hyatt is planning to migrate the hardcoded browser- and editor-bindings to xbl (to take advantage of his changes mentioned above), and we might also do the same change with xul keybindings. this should be dependent on those, and others, as they arise.

*** Bug 51233 has been marked as a duplicate of this bug. ***

updating with info from dup 51233 (typing in textareas is slow). note that the two crucial blockers at this moment are 47452 and 47395.

then there's bug 51392

yup.

and, of course, my own bug 50384

yup, although that might be considered a dup of this bug, since it's sort of meta-ish...

Adding mjudge to CC, since 50384 is assigned to him.

Bug 50384 is in no sense a meta-bug, nor a dup of this bug. It describes a distinct state that the editor can get into that is orders of magnitude slower than than usual.

and bug 52161..

major work in progress on many of these bugs. see 48758.

Old metta bug, with all tracked bugs resolved, marking fixed