Closed Bug 54163 Opened 25 years ago Closed 24 years ago

<STYLE ...> in page causes slow render and CPU peg

Categories

(Tech Evangelism Graveyard :: English US, defect, P3)

defect

Tracking

(Not tracked)

CLOSED WORKSFORME

People

(Reporter: oliver.fels, Assigned: evangelism)

References

()

Details

(Keywords: testcase, Whiteboard: wdormann@crosswinds.net)

From Bugzilla Helper: User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.16 i586) BuildID: 2000091312 Everytime I try to access the site mentioned above Mozilla completely hangs. No mouse events, no menus, nothing working. Have to shut it down by applying a kill command. It loads the page (the white background appears) then stops. Must be something with accessing a specific URL. Netscape 4.x works ok. Reproducible: Always Steps to Reproduce: 1.Enter the URL, pres Enter :) 2. Watch whats happening. Actual Results: Browser hung. Expected Results: Well, load and display the page. Environment: S.u.S.E. Linux 6.3, Kernel 2.2.16 224 MB RAM CPU AMD K6/2 450 Voodoo3 gfx card GTK 2.1.6 libs glib 2.1
Not sure whether this is a duplicate of #40855 or #42068 but it does not seem to be a parser issue from my point of view.
Oliver, Try leaving Mozilla on that page for a while. It may seem to hang, but at least on my system the page comes up after about 20 seconds. (During which time, Mozilla is using 100% available CPU time)
Right, it came back after 1 1/2 minutes. And you are right, it eats 100% CPU time (should have checked that before). Nonetheless it is a bug as no other browser shows that behavior.
Changed severity from critical to normal to reflect the appropriate state.
Severity: critical → normal
someone want to testcase this page and see what is casuing the CP pegging?
Keywords: makingtest
Whiteboard: wdormann@crosswinds.net
Well, it's not exactly a testcase per se, but here's where the problem is: <TR> <TD colSpan=2 width="100%"><IMG alt="Members Only" height=7 src="javasun2_files/chiclet.gif" width=7> <FONT face="Verdana, Arial, Helvetica, sans-serif" size=-1><STYLE="COLOR: none? text-decoration: #000000;><B>Requires login</B></FONT><BR><BR></TD></TR><!-- Begin header --> Or more specific, it is: <STYLE="COLOR: none? text-decoration: #000000;> If that section is removed from the page, it takes about 1 second to display, as opposed to 25 seconds on my Athlon 700
Status: UNCONFIRMED → NEW
Component: Browser-General → Parser
Ever confirmed: true
Keywords: makingtesttestcase
Reassigning...
Assignee: asa → rickg
Summary: Mozilla hangs when accessing site → <STYLE ...> in page causes slow render and CPU peg
The actual bug is that there is a 2nd <STYLE...> tag (line 213) in the given file. That <Style> tag has no </style>, and the parser is forced to scan the rest of the document looking for the </style>. When it doesn't find it, we back up. The fix is to correct the given html.
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → WONTFIX
so bad HTML is supposed to lock us up with teh CPU pegged, effectively disabling the rest of the computer then? I'm not sure I agree.
It's a rare case, so it's not worth fixing for RTM. The solutions are: 1. Ignore style altogether if it's not in the head (not backward compatible) 2. Terminate the search for the </style> sooner than EOF
how about terminating once you hit the next HTML tag?
Reopening...
Status: RESOLVED → REOPENED
Component: Parser → Evangelism
Resolution: WONTFIX → ---
Reopening and reassigning to Evangelism to see if they can convince Sun to fix the bad markup at http://developer.java.sun.com. It affects almost all the pages at JDC which makes me beleive the pages are generated and so it should be an easy fix for them (probably in 1 place). This bug is making the whole site pretty useless (30+ secs to render every page).
Assignee: rickg → evangelism
Status: REOPENED → NEW
OS: Linux → All
QA Contact: doronr → zach
Hardware: PC → All
I had a small E-mail discussion with somebody from Sun, and they could not find the offending code anywhere in their pages. I told them exactly what lines the problem was at, and also sent them the surrounding code so that they could see where it's at. No go. Perhaps somebody else will have better luck than I did....
*** Bug 59119 has been marked as a duplicate of this bug. ***
The content at the URL is as bad as before but there is no performance problem anymore. WORKSFORME, build 2001-01-13-08 on Windows 98 SE.
Status: NEW → RESOLVED
Closed: 25 years ago24 years ago
Resolution: --- → WORKSFORME
As the problem is fixed for long now, it is time to close that bug, as my reporting mail address will be changing in the very near future
Status: RESOLVED → CLOSED
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for details.
Component: Evangelism → US English
Product: Browser → Tech Evangelism
Version: other → unspecified
Product: Tech Evangelism → Tech Evangelism Graveyard
You need to log in before you can comment on or make changes to this bug.