clicking on text control form element too slow

VERIFIED FIXED in M18

Status

()

Core
Layout: Form Controls
P3
major
VERIFIED FIXED
18 years ago
17 years ago

People

(Reporter: buster, Assigned: mjudge)

Tracking

({perf})

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [nsbeta2-], URL)

(Reporter)

Description

18 years ago
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.
(Reporter)

Comment 1

18 years ago
M16
Status: NEW → ASSIGNED
Target Milestone: M16

Comment 2

18 years ago
keyword bingo
Keywords: perf
(Reporter)

Comment 3

18 years ago
*** Bug 24497 has been marked as a duplicate of this bug. ***
(Reporter)

Comment 4

18 years ago
performance work for text controls is at risk for FCS unless someone offloads 
some of my tasks.
Target Milestone: M16 → M19

Comment 5

18 years ago
nominating for nsbeta2 based on:
 - severity
 - visibility
 - major functionality broken
Keywords: nsbeta2

Comment 6

18 years ago
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-] 
Whiteboard: [nsbeta2-]

Comment 7

18 years ago
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

18 years ago
Reassigning to beppe (editor).
Assignee: buster → beppe
Status: ASSIGNED → NEW

Comment 9

18 years ago
Mike, hopefully the ender lite work will help resolve this issue
Assignee: beppe → mjudge
Target Milestone: M19 → M18
(Assignee)

Comment 10

18 years ago
ender-lite resolved this issue. no longer lazily instantiating the editor on 
focus.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 11

17 years ago
Updating QA contact.
QA Contact: ckritzer → bsharma

Comment 12

17 years ago
Verified build 2001080603 os:winNT
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.