webpage keeps cpu usage at around 100%

RESOLVED WORKSFORME

Status

()

Core
Layout
P2
major
RESOLVED WORKSFORME
16 years ago
12 years ago

People

(Reporter: Andrew, Assigned: Marc Attinasi)

Tracking

({testcase})

Trunk
Future
x86
All
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

16 years ago
i'm not sure exactly what is casuing the problem, but entering the url above
(http://siig.com/knowledge/index.html) will peg the cpu until the page is
closed. it's a small page but links to a javascript page that looks suspect.
this happens using mozilla 1.0 on both windows 2000 and linux rh7.3.

thanks

Comment 1

16 years ago
Another similar page: constant 25% CPU usage on Duron750
http://www.ropnet.ru/ogonyok/win/welcome.html

Comment 2

16 years ago
http://boyland.org/gayla/index.php, just loading the page causes CPU usage to
jump to 28% on a pIII.  There is a simple news scroller there.  Noticed on Linux
2002070508.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → All

Comment 3

16 years ago
http://blue-labs.org/~david/moz-profile-bug-154524.html has a few minutes of
profile data for this script.

Is it useful?

Comment 4

16 years ago
bug 154568 appears to point towards [part of] the problem, marking dependant
Depends on: 154568

Updated

16 years ago
Severity: normal → major
Component: Browser-General → Layout

Comment 5

16 years ago
I still see the 100% CPU pegging with the original url:

    http://siig.com/knowledge/index.html

and a build based on the MOZILLA_1_0_BRANCH. I don't see the problem using a
TRUNK build.

This is probably due to the fix that was checked into the TRUNK for jst's bug
123273 which enforces a minimum timeout of 10ms for calls to setTimeout(). The
url above is continuously using a timeout value of zero in it's awmdb() JS function.

Blu3, you might want to file a separate bug regarding your URLs rather than
morphing this bug ... that will allow us to close this bug out as a dup. Also
bug 154568 is a specific case dealing with the fact that the realtime
feel/repainting of a dhtml scrollbar was actually due to the fact that text
widgets were flushing paint requests ... so I'm removing the dependency since
the cause of the original reported bug is different.
No longer depends on: 154568
.
Assignee: Matti → attinasi
QA Contact: imajes-qa → petersen

Updated

16 years ago
Priority: -- → P2

Updated

16 years ago
Target Milestone: --- → Future

Comment 7

15 years ago
WFM (original URL) on Win XP, using Thrunk build of 12/16/02 and 1/03/03

The URL in #1 gives me around 7% CPU load and the URL in #2 gives me 2%.

Comment 8

15 years ago
OK, I see now with the original URL. Although my CPU load is lower then what
other people have reported, I do see in the status bar that the browser is
looking for more data.  IE loads essentially the same page, but NN seems to
think more is coming from the server.  I think the status bar at the bottom is
just wrong.  It may SAY sending request to siig.com, but the new page is already
loaded. Roll the mouse over the URLs and the status message changes momentarily,
then back again, like something is not telling that status message box that the
page is loaded. 
Keywords: testcase

Comment 9

12 years ago
marking WFM - Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

nothing useful here - original URL is gone and one or more of the other URLs (which may *not* even be the same problem given the cause was never identified) work just fine.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.