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)

x86
All
defect

Tracking

()

VERIFIED WORKSFORME

People

(Reporter: bugzilla-mozilla-20220926, Assigned: harishd)

References

()

Details

(Keywords: compat)

Attachments

(1 file)

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).
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: perf
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.
Component: Layout → Parser
Keywords: perf4xp
OS: Linux → All
Summary: Layout/render on this page is very slow → Long layout and high CPU on misplaced, unclosed STYLE tag
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.
*** Bug 60066 has been marked as a duplicate of this bug. ***
Currently (Moz build 2000122604) the page renders quickly for me.
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.
updated qa contact.
QA Contact: janc → bsharma
QA Contact: bsharma → moied
Keywords: compat
->harishd
Assignee: rickg → harishd
Status: ASSIGNED → NEW
Looks like the page has changed and not a problem any more. Marking WFM.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
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.

Attachment

General

Created:
Updated:
Size: