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.
It runs fine on my Win98 2000010108 build. However, I have a Celeron 550 with 128MB RAM
Assignee: nobody → trudelle
Component: Browser-General → XUL
QA Contact: nobody → paulmac
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 email@example.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 firstname.lastname@example.org
There is no XUL involved here. changing component to HTML Form Controls, reassigning to beppe since most of them are edit fields.
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 email@example.com and firstname.lastname@example.org. Reassigning the bug to email@example.com for further investigation.
I filed the TextField background color bug mentioned above as bug #23244.
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.
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.
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.
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → DUPLICATE
*** This bug has been marked as a duplicate of 17829 ***
Verified dupe of 17829
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.