clicking on a text control form element is too darn slow. there is a noticable lag while the docshell is created underneath the text control frame. This is the trade-off from moving to lazily-instantiated docshells (which was critical since docshells were very heavy weight, and loading pages with dozens of text controls could take minutes.) one thing I already did that improved performance and footprint dramatically was to go to synchronous docshell creation (nsIDocShell::SetDocument() instead of nsIDocShell::LoadURI()). That method could probably use some tuning. we're waiting to see what kind of performance boost we get out of lightweight widgetless docshells before doing any more performance work specifically on this problem.
*** Bug 24497 has been marked as a duplicate of this bug. ***
performance work for text controls is at risk for FCS unless someone offloads some of my tasks.
nominating for nsbeta2 based on: - severity - visibility - major functionality broken
Putting on [nsbeta2-] radar. Please provide metrics as to how slow compared to 4.73 or previous Seamonkey builds. If you still feel a beta2 blocker, remove [nsbeta2-]
Bug 24497 was marked as a duplicate of this bug. The problem there is that when you click the input field for the first time it will first repaint the area with some other content (randomly chosen depending on scroll position) and then repaint the proper text control. This is occuring both on Linux and Windows. Easily reproduced in bugzilla query page.
Reassigning to beppe (editor).
Mike, hopefully the ender lite work will help resolve this issue
ender-lite resolved this issue. no longer lazily instantiating the editor on focus.
Updating QA contact.
Verified build 2001080603 os:winNT