22379 - URL loads and then takes about a minute for browser to become responsive again.

Status: VERIFIED DUPLICATE of bug 17829

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

Description

[Stu Coates]

Mozilla Build: #1999122108
OS: Windows NT 4.0 + SP6
Hardware: Compaq Armada 7800 - 266Mhz PII, 160MB
Network: LAN/ISDN router

When the URL: http://www.filesys.demon.co.uk/stu/portal.html is loaded the
browser "goes away" for about a minute (on a 266Mhz PII) eating about 80% CPU.
Once it has recovered, everything is fine until the page is reloaded when the
"wait" happens again.

Comment 1

[Christian Mattar]

It runs fine on my Win98 2000010108 build.
However, I have a Celeron 550 with 128MB RAM

Comment 2

[Sean Richardson]

Tried this on a Pentium-120 machine; the same cpu-hogging and UI event freezing
happened, for most of a minute. During that time, the scrollbar updated once or
twice as more of the page appeared.

This looks like a performance problem with the instantiation of all the
form controls on the page (dozens). At that, some <input text> elements
still have the background colour within their borders when the page stops,
and these change to white inside when clicked on, so not all of them may
have been instantiated.

Guessing that lazy instantiation was turned off pre-M12, and no hack made it in
for bug 21887, "Input fields/text areas have focus/blur issues", ASSIGNED, M13
-- based on comments by [e-mail]  1999-12-16 12:04 on performance
expectations with eager vs. lazy instantiation. Or perhaps there are just so
many instantiations needed after loading that they starve *everything* else
even though they are lazy.

Tested with: 2000-01-03-08-M13 nightly binary on Windows NT 4.0sp3, 64MB,
several other apps running, 20MB swap in use.

Changing Component to "XUL" from "Browser-General"; Setting QA contact;
CC-ing [e-mail]

Comment 3

[Peter Trudelle]

There is no XUL involved here.  changing component to HTML Form Controls,
reassigning to beppe since most of them are edit fields.

Comment 4

[kinmoz]

The the problem here isn't the textfield/textarea instantiation, it has
something to do with the fact that the page uses nested tables.

When I remove all table tags from the file, the page loads quick.

The problem with the textfields picking up the background color of the table
cell is a bug that has to do with the fact that some of the input elements in
your html aren't specifying TYPE=TEXT and relying on the default value. I
believe we are using the style system to set the background color of the text
widgets, so the style rules might not be handling the fact that the input
element's default type is text.

Cc'ing [e-mail] and [e-mail].

Reassigning the bug to [e-mail] for further investigation.

Comment 5

[kinmoz]

I filed the TextField background color bug mentioned above as bug #23244.

Comment 6

[buster]

the background color bug has already been fixed, just not checked in yet.  I'll
mark bug 23244.

chris, if you want any help confirming performance metrics wrt text controls,
I'm available to help.

Comment 7

[Sean Richardson]

I think I have an idea what is going on here. When textfields and textareas
first render, they for some reason sprout extensions to the left (with
the normal left border still visible) before setting down to their normal size.
This can easily be seen by clicking on one of the textfields that still has
the background colour after loading. Now think how much table reflow dozens
of those happening at once, asynchronously, would cause, and how much that
would stress table reflow performance....

I am almost certain that there is an existing bug on the textfield temporary
misrendering; this bug may resolve itself once that one is fixed.

Comment 8

[buster]

nope, this has little or nothing to do with text controls.  These text controls
are very light weight.  They have no subdocument, just a little block frame that
displays whatever default text they might have. The painting problem you are
seeing is just a painting problem, and does not impact reflow at all.  That is
bug 22765 and is assigned to troy.  Fixing that bug is not expected to boost
performance very much (fewer paints are always good, but that's not what's
killing us here I suspect.)

What's killing us here is the raw number of reflows running through the system.
These are the result of the dropdown lists.  This is a known problem that Rod is
currently working on.  Rod, do you have a bug for this to dup this to?

Assigning to rods, cc karnaze.

Comment 9

[rods (gone)]

setting milestone

Comment 10

[rods (gone)]

*** This bug has been marked as a duplicate of 17829 ***

Comment 11

[Neil Marshall]

Verified dupe of 17829