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

VERIFIED DUPLICATE of bug 17829

Status

()

P3
normal
VERIFIED DUPLICATE of bug 17829
19 years ago
19 years ago

People

(Reporter: bugzilla, Assigned: rods)

Tracking

Trunk
x86
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

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

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

Updated

19 years ago
Assignee: nobody → trudelle
Component: Browser-General → XUL
QA Contact: nobody → paulmac

Comment 2

19 years ago
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 buster@netscape.com  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 hyatt@netscape.com

Updated

19 years ago
Assignee: trudelle → beppe
Component: XUL → HTML Form Controls

Comment 3

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

Updated

19 years ago
Assignee: beppe → karnaze

Comment 4

19 years ago
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 rods@netscape.com and buster@netscape.com.

Reassigning the bug to karnaze@netscape.com for further investigation.

Comment 5

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

Comment 6

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

19 years ago
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.

Updated

19 years ago
Assignee: karnaze → rods

Comment 8

19 years ago
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.
(Assignee)

Updated

19 years ago
Target Milestone: M14
(Assignee)

Comment 9

19 years ago
setting milestone
(Assignee)

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 10

19 years ago
*** This bug has been marked as a duplicate of 17829 ***

Comment 11

19 years ago
Verified dupe of 17829
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.