25947 - clicking on text control form element too slow

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect, P3)

Description

[buster]

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.

Comment 1

[buster]

M16

Comment 2

[Chris Waterson]

keyword bingo

Comment 3

[buster]

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

Comment 4

[buster]

performance work for text controls is at risk for FCS unless someone offloads 
some of my tasks.

Comment 5

[ckritzer (gone)]

nominating for nsbeta2 based on:
 - severity
 - visibility
 - major functionality broken

Comment 6

[leger]

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-] 

Comment 7

[Marko Macek]

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. 

Comment 8

[karnaze (gone)]

Reassigning to beppe (editor).

Comment 9

[rubydoo123]

Mike, hopefully the ender lite work will help resolve this issue

Comment 10

[mjudge]

ender-lite resolved this issue. no longer lazily instantiating the editor on 
focus.

Comment 11

[bsharma]

Updating QA contact.

Comment 12

[jerone]

Verified build 2001080603 os:winNT