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



18 years ago
4 years ago


(Reporter: oliver.fels, Assigned: evangelism)




(Whiteboard: wdormann@crosswinds.net, URL)



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

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

Comment 1

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

Comment 2

18 years ago

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)

Comment 3

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

Comment 4

18 years ago
Changed severity from critical to normal to reflect the appropriate state.
Severity: critical → normal

Comment 5

18 years ago
someone want to testcase this page and see what is casuing the CP pegging?


18 years ago
Keywords: makingtest
Whiteboard: wdormann@crosswinds.net

Comment 6

18 years ago
Well, it's not exactly a testcase per se, but here's where the problem is:

          <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
Component: Browser-General → Parser
Ever confirmed: true
Keywords: makingtest → testcase

Comment 7

18 years ago
Assignee: asa → rickg
Summary: Mozilla hangs when accessing site → <STYLE ...> in page causes slow render and CPU peg

Comment 8

18 years ago
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.
Last Resolved: 18 years ago
Resolution: --- → WONTFIX

Comment 9

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

Comment 10

18 years ago
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?
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
OS: Linux → All
QA Contact: doronr → zach
Hardware: PC → All

Comment 14

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

Comment 15

18 years ago
*** 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.
Last Resolved: 18 years ago18 years ago
Resolution: --- → WORKSFORME

Comment 17

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

Comment 18

17 years ago
All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
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.