Closed
Bug 339337
Opened 19 years ago
Closed 18 years ago
CPU at 100%, SeaMonkey is still usable, but it almost freezes.
Categories
(SeaMonkey :: General, defect)
Tracking
(Not tracked)
RESOLVED
WORKSFORME
People
(Reporter: batuque, Unassigned)
References
()
Details
(Keywords: testcase)
Attachments
(3 files)
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•19 years ago
|
||
Opera browser shows about 25% CPU usage,
IE - almost 0.
Comment 2•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
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•19 years ago
|
||
Comment 6•19 years ago
|
||
Comment 7•19 years ago
|
||
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•19 years ago
|
||
Problem also occurs in SeaMonkey trunk Linux
Keywords: testcase
OS: BeOS → All
It's seems that this is a confirmed bug.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 10•19 years ago
|
||
(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•19 years ago
|
||
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•19 years ago
|
||
*** Bug 339429 has been marked as a duplicate of this bug. ***
Comment 14•19 years ago
|
||
confirming for BeOS SeaMonkey (2006-05-15-trunk)
that patch for bug 335251 fixes the issue with idg.se
Comment 15•19 years ago
|
||
> 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•19 years ago
|
||
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•19 years ago
|
||
*** Bug 343111 has been marked as a duplicate of this bug. ***
Comment 18•19 years ago
|
||
This is a issue in the trunk builds also.
It is impossible to go to www.idg.se without the browser hanging
Updated•19 years ago
|
Severity: normal → critical
Comment 19•18 years ago
|
||
Bug 335251 has been fixed, so this is WFM now.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•