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

Status: CLOSED WORKSFORME

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

Description

[Oliver Fels]

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

Comment 1

[Oliver Fels]

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

[WD]

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)

Comment 3

[Oliver Fels]

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

[Oliver Fels]

Changed severity from critical to normal to reflect the appropriate state.

Comment 5

[Asa Dotzler [:asa]]

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

Comment 6

[WD]

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

Comment 7

[WD]

Reassigning...

Comment 8

[rickg]

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.

Comment 9

[Asa Dotzler [:asa]]

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

[rickg]

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

Comment 11

[Doron Rosenberg (IBM)]

how about terminating once you hit the next HTML tag?

Comment 12

[Mats Palmgren (inactive)]

Reopening...

Comment 13

[Mats Palmgren (inactive)]

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).

Comment 14

[WD]

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

[Bill Lipa]

*** Bug 59119 has been marked as a duplicate of this bug. ***

Comment 16

[Mats Palmgren (inactive)]

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.

Comment 17

[Oliver Fels]

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

[Bob Clary [:bc] (inactive)]

All Evangelism Bugs are now in the Product Tech Evangelism. See bug 86997 for
details.