Closed
Bug 54596
Opened 24 years ago
Closed 23 years ago
Long layout and high CPU on misplaced, unclosed STYLE tag
Categories
(Core :: DOM: HTML Parser, defect, P3)
Tracking
()
VERIFIED
WORKSFORME
People
(Reporter: bugzilla-mozilla-20220926, Assigned: harishd)
References
()
Details
(Keywords: compat)
Attachments
(1 file)
(deleted),
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; m18) Gecko/20000928
BuildID: 2000092808
The home page for the Java Developer Connection is very slow to layout and/or
render.
Reproducible: Always
Steps to Reproduce:
Navigate to the given URL, and notice that it takes over 30 seconds to be
displayed (on a Pentium III-450, with all page assets cached). With images off
(since there's a large animated GIF ad on the page) it's about 25 seconds.
Reload the page and notice it takes the same time; navigate to one of the links
then hit 'back' and notice it's also very slow to display.
This is Linux, so no Java applets getting in the way, either (in fact, there
aren't any on the page).
Comment 1•24 years ago
|
||
Yes, layout of this page is taking awhile longer. I get 38 seconds under Win 98
with N6. I 'm getting around 9 seconds for NS 4.7 to layout this same page. This
page doesn't contain any applets (according to it's page source). It does use a
lot of tables for it structure though.
Comment 2•24 years ago
|
||
The problem seems to be with the unclosed, incorrectly placed STYLE tag halfway
down the Sun page. This also pegs the CPU quite high. Tested on NT 4.
I've constructed the following simplified testcase without tables. The larger
the content after the unclosed STYLE tag, the longer it takes for layout. IE and
Nav 4 do this quite quickly.
Removing perf keyword. Adding 4xp. cc:ing Rick. Moving over to parser. Changing
OS to ALL. Creating better summary.
Comment 3•24 years ago
|
||
Comment 4•24 years ago
|
||
SPAM: really assigning this time...
Assignee: clayton → rickg
QA Contact: petersen → janc
The system is trying to locate a </style> tag -- and is forced to scan the
remainder of the document. We could constrain the search (given that the <style>
is in the body illegally). I'd probably just ship it as it, since the problem is
fairly unlikely.
Status: NEW → ASSIGNED
Assuming the <style> tag occurs *in* the <head>, one easy patch is to stop
searching for the </style> tag once you find the </head> or <body>. It won't
work universally, but it will handle the majority of the cases.
Comment 8•24 years ago
|
||
Currently (Moz build 2000122604) the page renders quickly for me.
Comment 9•24 years ago
|
||
In addition, Mozilla seems to add a </STYLE> after the offending STYLE tag.
This should not happen, even if it breaks the page, Mozilla should not be adding
tags in that weren't originally there. Tested on WinME, Win2K 2001010901.
Assignee | ||
Comment 12•23 years ago
|
||
Looks like the page has changed and not a problem any more. Marking WFM.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Comment 13•23 years ago
|
||
verified WFM with Build ID 20020404 using WINXP
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•