339337 - CPU at 100%, SeaMonkey is still usable, but it almost freezes.

Status: RESOLVED WORKSFORME

(SeaMonkey :: General, defect)

Description

[François Vincent]

User-Agent:       Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20060514 SeaMonkey/1.5a
Build Identifier: Mozilla/5.0 (BeOS; U; BeOS BePC; en-US; rv:1.9a1) Gecko/20060514 SeaMonkey/1.5a

Tried with Firefox 1.5.0.3 in Windows too. My computer is a Duron 700MHz, 384MB of RAM. Many users reported the same problem with that website.

Reproducible: Always

Steps to Reproduce:
1.Open the URL
2.Wait a few seconds
3.

Actual Results:  
SM or FF eats CPU

Comment 1

[Sergei Dolgov]

Opera browser shows about 25% CPU usage,
IE - almost 0.

Comment 2

[Jorge G. Mare (a.k.a. Koki)]

Test this URL using FF 1.5 in Ubuntu Linux, and CPU load is quite high during page loading, at times approaching 100%. Once the page is loaded, CPU usage drops, but scrolling the page is very "jerky" and CPU jumps to 100% during scroll.

Comment 3

[Gérard Talbot]

I tried the page at provided URL with Seamonkey 1.5a rv:1.9a1 build 2006052409 under XP Pro SP2 and the cpu %tage remained at 100% and the application became unresponsive. The RAM usage also was steadily growing (Windows task manager). There is no doubt that there is something wrong here.

I tried with javascript disabled and the page loaded without cpu/RAM usage problem.

There is a reasonable chance that this phenomenon is connected to the webpage incorrect user agent string detection.

function checkBrowser(){
	this.ver=navigator.appVersion
	this.dom=document.getElementById?1:0
	this.ie5=(this.ver.indexOf("MSIE 5")>-1 && this.dom)?1:0;
	this.ie4=(document.all && !this.dom)?1:0;
	this.ns5=(this.dom && parseInt(this.ver) >= 5) ?1:0;
	this.ns4=(document.layers && !this.dom)?1:0;
	this.bw=(this.ie5 || this.ie4 || this.ns4 || this.ns5)
	return this
}

Firefox and Seamonkey will return bw.ns5 as 0 (false) when the script function checkBrowser() should (assumed intented result, most likely) return 1 (true).

Comment 4

[Jorge G. Mare (a.k.a. Koki)]

Just to confirm oservations in comment #3, when testing the page using Firefox and/or Seamonkey in ZETA (a BeOS derivative), the page loads normally, and once loaded, CPU load goes down to 0. Scroll also works as expected in this case.

Comment 5

[Mats Palmgren (inactive)]

Attachment: script2 (loaded by script1)

Comment 6

[Mats Palmgren (inactive)]

Attachment: script1 (loaded by Testcase #1)

Comment 7

[Mats Palmgren (inactive)]

Attachment: Teastcase #1

This is testcase I got when reducing the scripts involved:
http://mi.adinterax.com/js/idgse,oracle_ws_follow_19063,C=oracle_ws_follow_1906,P=IDG/ad2.js?q=1147259760
http://mi.adinterax.com/customer/idgse/oracle_ws_follow_19063.ns.js?adxq=1147954998

Looks like a JS programming error to me...

Comment 8

[Mats Palmgren (inactive)]

Problem also occurs in SeaMonkey trunk Linux

Comment 9

[tqh]

It's seems that this is a confirmed bug.

Comment 10

[Mats Palmgren (inactive)]

(In reply to comment #9)
> It's seems that this is a confirmed bug.

Why?  If it is, what is the bug exactly?

Comment 11

[tqh]

Ok, I might have confirmed the problem instead of the bug, but being able to take the down the browser with faulty JavaScript seems to be a bug to me. Or should we just support perfect web-pages?

Comment 12

[Mats Palmgren (inactive)]

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

Comment 13

[Mats Palmgren (inactive)]

The patch in bug 335251 fixes the URL and Testcase #1.

Comment 14

[Sergei Dolgov]

confirming for BeOS SeaMonkey (2006-05-15-trunk)
that patch for bug 335251 fixes the issue with idg.se

Comment 15

[Boris Zbarsky [:bzbarsky]]

> but being able to take the down the browser with faulty JavaScript seems to be
> a bug to me

Except the browser is NOT taken down.  The summary says it's still usable; you can close the offending page, etc.

Comment 16

[Sergei Dolgov]

it is hardly usable, bz. At 2 GHz Thinkpad today I should wait about 5 minutes until it closed tab with that page (Win XP  SP2, some end of Aprill trun FF). Until that other tabs were unusable too

Comment 17

[:Gavin Sharp [email: [e-mail]]]

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

Comment 18

[Mats Åhlberg]

This is a issue in the trunk builds also.
It is impossible to go to www.idg.se without the browser hanging

Comment 19

[Olli Pettay [:smaug][[e-mail]]]

Bug 335251 has been fixed, so this is WFM now.