From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.9+) Gecko/20020426 BuildID: 2002042608 Visit this page http://www.ica.org.uk/index.cfm?articleid=4365 not too complicated and rendered easily by IE, but mozilla requires all the CPU time until the page is closed/hidden. Can't view page source but could be something to do with the scrolling message that renders correctly in IE but not in Mozilla. Reproducible: Always Steps to Reproduce:

Reproduced on rc1 (2002041711), Win2K: After the page loads, Moz runs near ~80% CPU, and drops down to 0% CPU approx. once every 3 seconds. CPU = PII-366

What am I missing? I can't reproduce the problem on that page, linux trunk build 2002-05-07-21.... no cpu usage. I can also view source just fine....

Confirming report with Mozilla trunk binaries 20020508xx. On both Linux and WinNT, my CPU varies along with the scrolling text, up to around 80-90% as reported in Comment #1. Changing OS: Win2K ---> All. Note: the font for the scrolling message seems to be white -(?) The only way I can see it is to do Ctrl+A to highlight the entire page in blue; then I can see the message. Does anyone else have that problem? Note: the message is printed inside a <SPAN> element with id='TypeIt'. To see this, you can load this javascript:URL javascript: alert(document.getElementById('TypeIt').innerHTML); If you keep loading this, you can see the scrolling message change. But of course, it's easier just to do Ctrl+A to highlight the page. In IE6, the scrolling text is visible without any tricks.

When I try the reduced JavaScript scrolling testcase in Mozilla, my CPU is completely quiet on both WinNT and Linux. This shows this is not a JavaScript performance problem. My guess is that there is some kind of reflow problem, but other people will know more about that than I do. I do notice some very strange "jumps" when I mouseover certain parts of the given URL... Note there are lots of occurrences of |window.location.reload()| in the JavaScript. If that gets called a lot, that would cause a lot of CPU, right? Unfortunately, I had no luck in the Mozilla JavaScript debugger to see how often these get called (the line numbering in the debugger seems to be far out of alignment). Reassigning to Layout for further analysis -

RE Comment #5: While this bug may not be a javascript performance problem, the javascript scolling message does not render correctly on Mozilla. Does this page identify another bug as well?

Changing QA Contact

emmet@cogs.sussex.ac.uk: you're right, if I'm not the only one seeing the CSS problem, we need to consider it as a separate issue. Are you having the same trouble as I: the scrolling text is invisible in Mozilla? Here is the HTML in question: else if (Lvl==3){ document.writeln(sTag+eTag); document.write("<span id='TypeIt' class='typeit'> <a id='AnchorIt' class='typeit'> <\/a> <br><\/span>"); Note the class 'typeit' comes from view-source:http://www.ica.org.uk/nsstyle.css /* News ticker tape */ a.typeit, a.typeit:LINK, a.typeit:VISITED, a.typeit:ACTIVE, a.typeit:HOVER, p.typeit, .TypeIt #TypeIt { color : #999999; font-size : 11px; } I can confirm that #999999 is a gray color, which is what the scrolling text looks like in NN4.7 and IE. For some reason, that is not happening in Mozilla; I don't know enough CSS to debug why. Boris, what do you think? Is this a known bug? Or is there a simpler explanation? Thanks -

Note: as for the CPU performance problem at the site, today I am not seeing it! Using the same Mozilla builds as yesterday: CPU WinNT 0-4% CPU Linux 0-30% emmet@cogs.sussex.ac.uk: are you still having the CPU problem?

I think this is a mistake on the site's part. The HTML is: <span id='TypeIt' class='typeit'> <a id='AnchorIt' class='typeit'> </a> <br></span> Text is dynamically inserted into the <a> _and_ into the <span> outside the <a>. The text outside the <a> is what's invisible, which makes sense -- there is no style rule matching the span, so it inherits the (white) color from the <td>

Boris: thanks! I have filed Evangelism bug 143301 on this site: "CSS mistake makes scrolling text invisible" and cc'ed both you and emmet@cogs.sussex.ac.uk -

Note: I am still finding the CPU maxing out problem (build 2002042608).

You might want so check http://www.stern.de/ as that page also sets cpu load to 100% mozilla...

I downloaded Mozilla as I was getting such slooow performance with IE 5.5 when using the GUI that comes with the Cisco VPN concentrator. It seems to trigger when you use the expandable menu system on the LHS - I think this is all javascript. IE 5.5 is slow, but it doesn't get driven to 100%, the machine remains usable. I've attached a screen grab to illustrate. You can't replicate this problem unless you have a VPN concentrator - so I guess I'm willing to help troubleshoot this bug. I'll also raise it as a case with the Cisco TAC. I'm running : Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0rc3) Gecko/20020523 darren.

Cisco VPN 3000 GUI drives mozilla to 100% CPU.jpg

Exactly the same problem with a more recent build. Mozilla 1.0 Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.0.0) Gecko/20020530 I see that the target milestone is set to "future" Obviously it's more important to do stuff like : Browser tabs now close left to right (they used to close right to left). http://www.mozilla.org/releases/mozilla1.1a/#new than debug javascript issues that render the browser useless. darren.

Using trunk build 2003020308 on winxp pro sp1,512ram things are quite fine. darren, do you still see this?

the site from #1 works for me Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4b) Gecko/20030526 Mozilla Firebird/0.6 But there is another quite easy script thats eating my resources. (CPU usage from MozFB up to 80-90% ) Take a look at http://shortnews.stern.de/nt.cfm This is a simple Jaca-Script News-ticker. I hope this bug is close to the topic, but i watn to avoid another duplicate :)

Fine, let's take this as the testcase. A profile here would be very helpfull.

Cannot confirm testcase. It consumes only about ~8% of my CPU (Athlon 1.8Ghz), link from Comment #18 consumes about 50% of CPU. (WinXP)

Using trunk build 2003052504 on win-xp pro sp1, 512ram, geforce 2 go 32ram vcard I have 100% cpu usage. Might this also be gfx related?

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

reassigning to default layout owner.

For the code in comment 18, if you change this line: ticker = new Ticker('ticker', 'tickerID', 1, 22); to this: ticker = new Ticker('ticker', 'tickerID', 1, 100); CPU usage drops dramatically. Still investigating the situation, but I thought you might like to know. Seems like the script is polling something faster than Moz expected. -M

Okay, here's the problem, as far as I can deduce it-- The ticker runs by calling the startTicker() function every time it wants to move the text over. The startTicker function "loops" by calling setTimeout( ) on itself with a certain value. (That's the value that we changed from 22 to 100 in the above comment.) That is, whenever startTicker() runs, it then runs itself again after a specified number of ms. As far as I can tell, the problem seems to be either in: 1) setTimeout() 2) The overhead of function calls. 3) Something that happens in startTicker() I'd bet on #1, but it might be something else. The JavaScript of the ticker isn't well-designed, but IE doesn't choke on it like Moz does. If it helps, it's clear that the function spends most of its time in: this.runId = setTimeout(this.name + '.start()', this.interval); (If the JS is a bit confusing, it's because start() is an alias for startTicker().) Since the debugger will always stop there when I press the stop button in the debugger. -M

> If it helps, it's clear that the function spends most of its time in: The debugger (Venkman) includes a profiler, so you could find out where it actually spends the time....

It looks like I was wrong in my previous comment. The slowdown actually has to do with rendering content that is in hidden in the overflow, something which Moz seems to do and IE doesn't. (That is, IE seems to assume that anything outside the box with overflow: hidden doesn't exist. Moz doesn't seem to do the same thing.) Here is a reduced testcase that slows Mozilla, but not IE.

And here is one that slows both Mozilla and IE. That is, this testcase will cause the CPU to hit 100% in IE. The only difference is that on line 9 I've commented out "overflow: hidden". Otherwise the file is exactly the same. -M

My sightings to this: When I set the scrolling text to display:none, the cpu usage is nearly 0%. Also i noticed when the array with the news headlines has more than 10 entrys, cpu usage increases from 20% to 50%. Also in my testcase i disabled the real scrolling, only the javascript is working and cpu usage is still very high (see http://mcsmurf.privat.t-online.de/perf/shortnews.html for version with disply: none and http://mcsmurf.privat.t-online.de/perf/shortnews2.html for version with normal display).

roc, do we still paint stuff in the overflow:hidden case? I would assume we do not.... We _do_ have to lay out the overflow:hidden content, however (since we don't know it's hidden 'till we lay it out).

Paint flashing shows that we're not invalidating any more than what's actually visible. Would be interesting to see a profile to see if the time is in rendering or layout, but I suspect layout.

I actually did do a profile; it showed almost no time spent anywhere. That was a non-real-time profile, though. I will try to do a realtime one.

Looks like style reresolution and reflow are the two main things here (this is a realtime profile).

Should style reresolution even happen on hidden content? (Well, I suppose if it becomes unhidden, then Moz would have to catch that...) Also, it certainly seems like reflow shouldn't happen on hidden content. Reflowing the displaying ticker it totally understandable, but why reflow the parts of the ticker that don't actually display? I'll have to admit, I'm not an expert on Moz architecture, so I don't already know the answers to these questions or even if they're valid questions to begin with. -M

> Also, it certainly seems like reflow shouldn't happen on hidden content. Except that it can affect the display of non-hidden content... consider: <div style="overflow: hidden; height: 1em"> Text<br> More text that is hidden <span style="position:relative; top: -1em">Visible text</span> </div> Consider what happens if I remove the string "hidden" from the textnode. Should I reflow the text? It's hidden, after all.... Same applies to style resolution, of course.

I am not sure if this is the same bug, but it sounds very similar (javascript scrolling some tickers on the page). I see this when going to any story off http://msnbc.msn.com/id/3032222/ such as http://msnbc.msn.com/id/6454255/ I am using Firefox Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0 I see Firefox using 100% cpu, and on the same page, IE uses 30-40%. Additionnaly the tickers are very slow in Firefox, but pass by pretty fast on IE. Could it be a blit issue?

> I am not sure if this is the same bug, but it sounds very similar (javascript > scrolling some tickers on the page). > I see Firefox using 100% cpu, and on the same page, IE uses 30-40%. > Additionnaly the tickers are very slow in Firefox, but pass by pretty fast on IE. Scrolling messages, tickers affecting cpu resources should be filed as duplicate of bug 137584. FWIW, I loaded/visited the page http://www.ica.org.uk/index.cfm?articleid=4365 and the cpu usage was very normal, =~ 0%. I also loaded/visited the page http://shortnews.stern.de/nt_v2.cfm and the cpu usage was very normal, =~ 0%. Mozilla 1.8b build 2005020905 under XP Pro SP2 here. WORKSFORME

Bug 137584 and this bug cover the same topic, issue and problem. I added a few words in the summary to help bugzilla searches. The 2 provided testcases are good so I'm not going to resolve this bug. I reiterate that the page http://www.ica.org.uk/index.cfm?articleid=4365 does not show in any way some kind excessive cpu usage while http://shortnews.stern.de/nt_v2.cfm still does not render a cpu problem. Mozilla 1.8b2 build 2005060206 under XP Pro SP2 with a modest 600Mhz cpu.

Please try a recent build, doing so I get fine results and this is WFM.

Please try a recent build, doing so I get fine results and this is WFM.

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

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051110 Firefox/1.5 http://shortnews.stern.de/nt.cfm doesn't show this bug, but the attached testcases do.

> the attached testcases do (show this bug). Correct. I tweaked the summary to help searching for duplicates. I think the webpages showing the high CPU %tage problem should be evangelized to 1- use/implement DHTML scrolling message/newsticker like explained in the tutorial http://developer.mozilla.org/en/docs/DHTML_Demonstrations_Using_DOM/Style:Stock_Ticker ( see this excellent web standards compliant example: http://developer.mozilla.org/samples/StockTicker/ ) or 2- invited to implement the use of <marquee> directly in the markup code (http://shortnews.stern.de/nt_v2.cfm does not do that directly) (e.g.<marquee scrollamount="10" scrolldelay="20">) and just like the fix in bug 156979 has permitted. NS 7.2 and Mozilla 1.4+ emulates support for <marquee>. Generally speaking, none of these alternatives cause cpu/performance problems.

I have found something similar on http://www.lesoir.be/ . There's a periodic ticker on the page, and each time it starts scrolling, Firefox eats 100% of my CPU, and the text scrolls very slowly (despite the fact that I'm running on a 3GHz system). Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8) Gecko/20051102 Firefox/1.5

> http://www.lesoir.be/ . There's a periodic > ticker on the page (...) Yes. It's definately caused by the vertical ticker scrolling intermittently. I think this issue (cause, explanations) should be added in the release notes so that people get aware of this issue and get aware of safe, sane and adequate alternatives (from a performance perspective; mentioned in comment #43). Adding relnote keyword There is also another interesting issue regarding that lesoir.be site: if lesoir.be is loaded in, say, tab A and you're reading in tab B, then the cpu %tage will max when the scrolling ticker is being updated (because the scrolling is DOM-based and DHTML-based), even if tab A does not have focus. This does not happen in other DHTML marquee webpages. I'm increasing Severity to major for 3 reasons: - when the CPU is maxed, the application is more prone to crashes otherwise the application becomes more unresponsive affecting user experience - the number of duplicates for this bug is higher than 16; I just counted 13 duplicates in recently resolved-as-DUP bug 137584 - the number of sites using DHTML-based scrolling text/marquee causing this bug is much higher than what bug 137584 and this bug may tell

Blocking bug 21762

Just sharing my workaround for such sites with you: Add the ticker's iframe to AdBlock. That's it - there's no scrolling ticket. You lose the ticket, of course. I did this a long time ago, because there a news site I like to read which has a ticker like that - and I don't really need the ticker.

Tested: WinXP Pro SP2 - Deer Park Alpha 2 - CPU Time: 0% PIII - 700mhz I could not recreate this bug.

(In reply to comment #47) > Just sharing my workaround for such sites with you: > Add the ticker's iframe to AdBlock. That's it - there's no scrolling ticket. The problem is, not all sites use an iframe to implement a ticker. On http://www.lesoir.be/ for example, it's virtually impossible to block with Adblock, because the ticker is a <script> embedded within the body of the document, and since Adblock can only block externally linked scripts, it's no use.

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

9 bugfiles (bug 280645, bug 235694, bug 260340, bug 289681, bug 297457, bug 315444, bug 316240, bug 322250, bug 137584) have been about the same website: http://www.ynet.co.il/ Therefore, I decided to open a Tech Evangelism bugfile (see bug 322288) for this. If anyone of you is fluent in Hebreu, then I sure would appreciate a hand in, for starters, determining the webmaster email address (or help or support email address) from ynet.co.il website. I'm trying to reach the ynet.co.il's webmaster.

(In reply to comment #51) > 9 bugfiles (bug 280645, bug 235694, bug 260340, bug 289681, bug 297457, bug > 315444, bug 316240, bug 322250, bug 137584) have been about the same website: > http://www.ynet.co.il/ > Therefore, I decided to open a Tech Evangelism bugfile (see bug 322288) for > this. If anyone of you is fluent in Hebreu, then I sure would appreciate a hand > in, for starters, determining the webmaster email address (or help or support > email address) from ynet.co.il website. I'm trying to reach the ynet.co.il's > webmaster. looking thru ynet.co.il, the only address i could find is a tech support address, for probobly tech support... webmaster's specific address is not to be found (yet) tech support e-mail: help@y-i.co.il maybe they can offer some insight

Another site where this problem is really bad: www.eurosport.com - 80% CPU load on 3.2G P4 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051219 SeaMonkey/1.0b. Internet explorer generates no noticeable CPU load when viewing this page, removing the ticker code from the page (<tr><td class="tickerheader">...</td></tr>) brings mozilla CPU usage down to 0-1%.

This bug is also noticeable when visiting http://www.vu.lt/ivykiai/. Weird though, I only see it in Linux. On Firefox/windows, this site loads just fine, meanwhile on for example, Firefox 1.0.7 on Ubuntu/PPC and Firefox1.5 on Ubuntu/x86 this page makes the CPU load graph rise to 100%, and in case of the PPC, the newsticker hardly even scrolls.

A nasty bug that's been around a long time now. Just setting block requests to put it back on the radar.

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

An unpatched ancient bug is not appropriate for a security/stability release -- please see the release criteria. If the trunk gets patched and tested and the patch looks safe then we can consider that for a branch. Is this still happening? We're not seeing it on Windows, but might be seeing it on Mac.

(In reply to comment #57) > > Is this still happening? We're not seeing it on Windows, but might be seeing it > on Mac. > Not seeing it on an Intel mini running the intel firefox build available at http://wiki.mozilla.org/Mac:Intel

Yes, this bug still exists in Mac OS X, 10.4.5, using the latest Firefox nightlies. Tested using a 2x1 GHz G4. The bug summary is misleading, though, in that the CPU % isn't necessarily "maxed", but is pushed very high, so adusting accordingly. The two test cases for this bug, as well as attachment 142487 [details] from bug 235694, still push the cpu usage to above 50% on my system (from only 1-3% beforehand). The ticker moves in a jerky motion instead of smoothly, and it visibly affects the performance of other pages in Firefox... page scrollbars are slow to move, etc. Scrollbars in other browser windows often seem to be worse affected than tabs in the same window.

http://www.chinatimes.com is another example. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060511 Minefield/3.0a1 ID:2006051106

(In reply to comment #60) > http://www.chinatimes.com is another example. > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060511 > Minefield/3.0a1 ID:2006051106 > On my Core Duo Mac Mini running Mozilla/5.0 (Macintosh; U; Intel Mac OS X; en-US; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3 that page only causes Firefox to run at about 20% CPU load (and, with the screwy way Apple's activity monitor works with dual cores, that's 20% of a single core)... Peace

Hi, I would like to report that going from 1.5.0.3 to 1.5.0.4 seems to have made this problem somewhat better. Or else it is an illusion. Can anyone verify a change from 1.5.0.3 to 1.5.0.4? Furthermore, is anyone working on this issue. I find it bizarre to call this an evangelism issue. Excuse me, a poorly coded application makes the CPU go through the roof, and this is an evangelism problem? I do not think so. Evangelism issues do not make the CPU spike so hard that the browser, not to mention the OS, is unusable. Can anyone show me a changelog for 1.5.0.4? Also, is anyone working on Firefox CPU bugs? They seem to be pretty prevelant, judging from my research.

(In reply to comment #62) > Also, is anyone working on Firefox CPU bugs? They seem > to be pretty prevelant, judging from my research. There's no Firefox "CPU" category for bugs, but if you are seeing a number of different bugs that affect cpu usage, then please search Bugzilla, and if they don't already exist then please create them. Thanks!

(In reply to comment #62) > > I find it bizarre to call this an evangelism issue. Excuse me, a poorly coded > application makes the CPU go through the roof, and this is an evangelism > problem? I do not think so. Evangelism issues do not make the CPU spike so hard That is exactly what I think and therefore bug 322288 should mark as duplicate?

(In reply to comment #64) > (In reply to comment #62) > > > > I find it bizarre to call this an evangelism issue. Excuse me, a poorly coded > > application makes the CPU go through the roof, and this is an evangelism > > problem? I do not think so. Evangelism issues do not make the CPU spike so hard > > That is exactly what I think and therefore bug 322288 should mark as duplicate? > Yes Nir, it is definitely a dupe of this bug. Go and mark it if you wish. As of 2004, Ynet was making its site Windows-IE only. They were not supporting other browsers, nor supporting Macs. I assume that is still the problem. If you live there, maybe you could write to them and ask them why they still have thier heads up their yazoos. In a sense, this is evangelism, because the site apparently refuses to work with Moz (though pls check on this, as our info is 2 yrs old), in another sense, as you and I agree, no way does an evangelism issue make the CPU freeze our boxes. There are many CPU bugs on Firefox and they appear to be longstanding. With some research maybe we can track them down. No one even appears to be working on the issue and no one understands it either. It's a perfect candidate for coders to look at. Based on my research, CPU bugs in Firefox are going to be hard to fix. People are talking about whether or not the whole codebase needs a rewrite and whether the CPU bugs are leftover from Netscape 4x. This, to me, implies a problem deep within FF's code that is going to be difficult to ferret out. Do you know of any applications that can measure and detect a CPU-spiking bug? Since the app does not crash and stays up, I think it would be hard to debug.

> is anyone working on this issue. No. As you can see in this bugfile, there is an "assigned to" field which currently says "Nobody's working on this, feel free to take it" > I find it bizarre to call this an evangelism issue. bug 142994 *is not* an evangelism issue. On the other hand, bug 322288 *is* an evangelism bug. ynet.co.il can adapt, update its javascript-DHTML code to make their marquee-like <div> run smoothly and accordingly (as expected) without hogging the CPU of Firefox users, and this, either with or without my assistance. It would even do the same (visually and cpu-wise/user system resources) for other W3C web standards compliant browsers. More than 4 years ago, D. Rosenberg (among many other articles, demos related to DHTML-marquee) created this W3C web standards compliant webpage: http://devedge-temp.mozilla.org/toolbox/examples/2002/xb/xbMarquee/examples/ch-js-loader.html > Excuse me, a poorly coded > application makes the CPU go through the roof, and this is an evangelism > problem? Please read carefully the summary of bug 322288. ynet.co.il can adjust their code by using what's available in the tutorials and articles provided at comment #0 of bug 322288. In particular, the expected results of bug 322288. Thank you for your understanding here.

Need to retest when reflow branch lands.

(In reply to comment #57) > An unpatched ancient bug is not appropriate for a security/stability release - > > Is this still happening? We're not seeing it on Windows, but might be seeing it > on Mac. Yes, this bug is happening on a variety of pages with Firefox. In particular, http://www.debka.com, not to mention Ynet. http://israelnn.com is another one. Here is another one: http://www.royalsplendourofmysore.com. This is NOT a Mac-only problem. Furthermore, this type of CPU-hogging bug has been present in a variety of forms for years now on Firefox and Mozilla. Particularly bad are Flash anything and often animated gifs. Anything that moves on the page is a possible suspect.

(In reply to comment #68) > Furthermore, this type of CPU-hogging bug has > been present in a variety of forms for years now on Firefox and Mozilla. > Particularly bad are Flash anything and often animated gifs. Anything that > moves on the page is a possible suspect. Those are not necessarily due to one bug, though there may be a common underlying problem. The most helpful thing you can do is pull the pages apart to determine the minimal code required to spike the cpu (e.g. will a single animated gif do it?), then reporting them as separate bugs (if they don't already match known bugs).

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

(In reply to comment #70) > *** Bug 318396 has been marked as a duplicate of this bug. *** > From Bug 318396, http://www.maariv.co.il consumes 80% CPU load for me Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060924 Minefield/3.0a1 ID:2006092404 [cairo]

When visiting http://free.grisoft.com/doc/2/lng/us/tpl/v5, CPU usage of Firefox rises to about 20%, and Xorg starts eating about 80% to 100% in Ubuntu..

www.godelta.de also shows this bug with iceweasel 2.0.0.3 / Debian etch, Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.1.2) Gecko/20070208 Iceweasel/2.0.0.2 (Debian-2.0.0.2+dfsg-3) and earlier versions also

(In reply to comment #72) > When visiting http://free.grisoft.com/doc/2/lng/us/tpl/v5, CPU usage of Firefox > rises to about 20%, and Xorg starts eating about 80% to 100% in Ubuntu.. It raised to 80% but very briefly, under a second. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070416 Minefield/3.0a4pre ID:2007041610 [cairo] (In reply to comment #71) > (In reply to comment #70) > > *** Bug 318396 has been marked as a duplicate of this bug. *** > > > > From Bug 318396, http://www.maariv.co.il consumes 80% CPU load for me > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20060924 > Minefield/3.0a1 ID:2006092404 [cairo] > You mean this page http://www.nrg.co.il/online/HP_0.html right? It consumes 40-50% CPU load constantly.

This remains slow for me on OS X, with firefox jumping to 70-80% CPU and remaining there consistently. I can provide a profile from shark if that is interesting.

(In reply to comment #74) > (In reply to comment #72) > > When visiting http://free.grisoft.com/doc/2/lng/us/tpl/v5, CPU usage of Firefox > > rises to about 20%, and Xorg starts eating about 80% to 100% in Ubuntu.. > > It raised to 80% but very briefly, under a second. > > Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a4pre) Gecko/20070416 > Minefield/3.0a4pre ID:2007041610 [cairo] > > (In reply to comment #71) > >... > > You mean this page > http://www.nrg.co.il/online/HP_0.html > right? It consumes 40-50% CPU load constantly. ~85% for me, **without the flash images Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070530 Minefield/3.0a5pre ~8% on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.2) Gecko/20070219 Firefox/2.0.0.2

Ouch, 100% for me with a current win32 trunk build

Here another page which make Firefox consume 100% forever http://cadivi.gov.ve/ then click on [Usuarios Registrados]

Here's an excellent example of this kind of site: <a href="http://www.wcax.com">www.wcax.com</a> Although this local news site is flash heavy the actual culprit is the thin red scroll bar incorporating yellow text links located at near top of the page. This scroll bar consumes 98% to 99% CPU usage when bar is scrolling. Hover over on of the text links, bar stops scrolling, CPU usage returns to 0% to 20% (spikes due to Flash based moving images and embedded scripts). The strange thing is that Firefox 2 nor IE 7.0 is not adversely affected by the scroll bar so this might be a good comparison test case situation at least for this particular part of this bug in other words: why one and not the other?

Here's an excellent example of this kind of site: http://www.wcax.com Although this local news site is flash heavy the actual culprit is the thin red scroll bar incorporating yellow text links located at near top of the page. This scroll bar consumes 98% to 99% CPU usage when bar is scrolling. Hover over on of the text links, bar stops scrolling, CPU usage returns to 0% to 20% (spikes due to Flash based moving images and embedded scripts). The strange thing is that Firefox 2 nor IE 7.0 is not adversely affected by the scroll bar so this might be a good comparison test case situation at least for this particular part of this bug in other words: why one and not the other?

Sorry for the double post. New to Bugzilla

(In reply to comment #78) I didn't experience the problem. Clicking the button you said to click led me to an error message: "app.cadivi.gov.ve uses an invalid security certificate...." (In reply to comment #80) I don't experience the same problem with 2008022104 build. The bar with moving text does increase CPU utilization but not often beyond even 30% (I have a 1.7 GHz dual core CPU). The scrolling starts after worldnow.com is allowed (I am using NoScript extension). I have Flash disabled.

Roman R, Thanks for checking this out. I'm using the same build as you are but you need to enable flash in order to see this happen. Considering Firefox comes "out of the box" with flash, Java and scripts enabled then it needs to be tested that way. My apologizes for not being clearer. I'll also state that no plugins were enabled during my tests so it was just Firefox exhibiting the problem and not some other contributing factor. Actually this is good since it shows that this is mostly likely a previously fixed flash based problem that has cropped up again in Firefox 3.

Enabling Flash significantly increases CPU utilization. The reason I didn't enable at first is to help isolate the problem, and this has shown that the moving text isn't the problem. However, your description (hover above the moving text, etc.) contradicts that. Seems like a complicated issue.

Flash has nothing, absolutely nothing to do with this bug. Refrain from posting comments unless you are sure it will help fix the bug. We already have lots of examples and testcases right now. Posting more will more likely make developers stay away from this bug. Vote for this bug or submit a patch: there is nothing else/better to do right now. Make sure you read the following webpage before posting: Bugzilla Etiquette https://bugzilla.mozilla.org/page.cgi?id=etiquette.html

Okay, understood now. I just had verification on the Firefox builds forum from another tester that saw the same behavior I did using the latest build. He also viewed the same site using Firefox 2.0.0.x and verified that CPU usage remained normal (less than 30%). The fact that this problem isn't seen in Firefox 2 makes this even more complicated in that the problem must have been already addressed and solved previously. Unfortunately I haven't yet the required knowledge to successfully troubleshoot this. Considering that this seems to be a regression should this be renominated as a possible blocker? I'm too new at Bugzilla to know how to do this successfully.

(In reply to comment #85) I shall indeed read the etiquette page however, the problem still exists and and did not exist previously. I'm merely trying to point this out. I'll take your advice and vote.

(In reply to comment #68) > (In reply to comment #57) Is it a vista problem? I only noticed the Debka.com ticker slowdown since I "upgraded" to Vista. I am at SP1 Thanks

(In reply to comment #88) > (In reply to comment #68) > > (In reply to comment #57) > Is it a vista problem? I only noticed the Debka.com ticker slowdown since I > "upgraded" to Vista. I am at SP1 > > > > Thanks > No its not Vista only AFAIK, this bug has been around for a long time now, and I ran into it while using XP SP2, and still there on Vista. Using today's latest trunk build - Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9b4pre) Gecko/2008022806 Minefield/3.0b4pre Firefox/3.0 ID:2008022806

Reported: 2002-05-08 This issue is going to be critical. Several pages make Firefox to get 100% CPU, normally if they has javascript which manipulate pop up windows or set DIVs non displayable.

Not sure what you mean by "going to be critical". The bug has been present in every Firefox that has ever shipped (and several Mozilla versions before there _was_ a Firefox), so it's not a regression. Why would it become more critical now? Crowder: attach the shark if you have it, it can't hurt.

(In reply to comment #91) > Not sure what you mean by "going to be critical". The bug has been present in > every Firefox that has ever shipped (and several Mozilla versions before there > _was_ a Firefox), so it's not a regression. Why would it become more critical > now? > > Crowder: attach the shark if you have it, it can't hurt. > @Mike, Although the problem I mentioned is indeed caused by a script powered "news ticker", it's different from this long standing bug and has been resubmitted by Martijn Wargers as bug 420715. The difference being that this new bug is not seen when using version 2.0.0.x. I still have to learn the ropes here at Bugzilla, hence my mistake.

The interesting bits: 0.0% 93.2% XUL JSD_GetValueForObject 0.0% 93.1% XUL JSD_GetValueForObject 0.0% 93.1% XUL GetSecurityContext(JNIEnv_*, nsISecurityContext**) 0.0% 93.0% XUL NS_GetComponentRegistrar_P After that, I seem to be missing a lot of symbols in my XUL lib. Will try to figure out why it's stripped when the rest of my opt build is not and post more later.

Those symbols are unlikely to be correct, and are instead likely to be the public symbol immediately preceding the function you're actually in.

I can reproduce this problem on this site: http://www.gamers-congress.de with Beta 5.

i can confirm this bug on kubuntu 8.04. some websites causes firefox (either 2.0 or 3 beta) to use massive amount of CPU. (firefox CPU usage may go beyond 90% on these sites, and my box is Pentium D 3.2Ghz with 2 GB RAM). the best example for these sites is http://www.keshet-tv.com/nehederet/, but others may also include http://www.ynet.co.il . once i installed the addon NoScript the CPU usage remained low on the above sites i mentioned. The bug does not reproduce in Opera browser.

<<<- those websites don't use headlines so maybe they changed the layout. Best example of headline bug is http://news.softpedia.com/ <- on IE6 and IE7 you can hold your mouse arrow on headline and then it underlines and pauses until you move your mouse arrow away from headline what isn't possible on Firefox or Minefield. Anyone has tutorial or something to help out the BUG for Gecko based Firefox? And if anyone can test if there is Firefox or Minefield version without the bug then it would be stepfoward to resolving? And if we can't fix it then we should block those kinds of headlines?

http://www.buycomputers.co.za/default.htm 99% CPU on Firefox 3.0 (when moving)

(In reply to comment #99) > http://www.buycomputers.co.za/default.htm > > 99% CPU on Firefox 3.0 (when moving) There seems to be a regression between Firefox 2 and Firefox 3 regarding that site, so I filed bug 442797 for that.

(In reply to comment #100) > (In reply to comment #99) > > http://www.buycomputers.co.za/default.htm > > > > 99% CPU on Firefox 3.0 (when moving) > > There seems to be a regression between Firefox 2 and Firefox 3 regarding that > site, so I filed bug 442797 for that. > Hi there. I'm here to register another website which has a javascript newsticker high CPU problem but just wanted to confirm, in passing, that I too have replicated the the problem at http://www.buycomputers.co.za/default.htm (and that no such CPU probs exist with IE7 rendering the same site). Anyhow, when visiting http://www.fixtureslives.com, I get severe CPU usage, which I believe I've tracked down to a "ticker.js" function on the main pages. If you hover the mouse pointer/focus over the ticker, it stops and CPU usage falls to virtually nothing. If you don't halt the ticker, things slow down massively with FF3, to the point where subsequent javascript data calls start failing too - the site holds amateur sporting data like leagues & fixture data for various sports (and the data retrieval I'm referring to is simply browsing a sport like hockey & trying to retrieve match dates for my club, which is in a particular league). Although I do use NoScript (and there's plenty of javascript on the site), I was only able to block the ticker using the "Stylish" addon and disabling it altogether (this fix was kindly supplied by NoScript's developer). The site seems to work ok with the ticker inactive. Also, the site works fine with firefox 2, even with the ticker running! Finally, the site renders perfectly, with little CPU usage, when IE7 is used (obviously on the same PC/hardware). Given the fact that IE has no problems with the site + having read some of the other problems encountered (in this thread, etc), it's starting to sound that FF3 just doesn't handle javascript very well sometimes. Useful info: Am running FF3.0 on XP SP3, with all the latest updates for my addons. My version of IE7 is 7.0.5730.11 Regards, Gary

I can also confirm it on Fedora 9 at this webpage: http://www.bochumtotal.de/ When scrolling, my music stops to play so it seems to have heave cpu usage.

(In reply to comment #101) > Anyhow, when visiting http://www.fixtureslives.com, I get severe CPU usage, > which I believe I've tracked down to a "ticker.js" function on the main pages. I can just barely reproduce this (my CPU will flirt with 20%, 0% when I hover.) I think your URL was supposed to be http://www.fixtureslive.com/. I tried stripping things out to make a reduced test case, but it became hard because it seemed like everything I cut out was reducing my CPU usage. Regardless, the following definitely affect it: 1. Removing the search form on the left of the ticker. 2. Removing the ad (even though I'm using Adblock and don't see it.) 3. Removing the CSS (this makes the ticker render white on white.) Anyway, if you can download a local copy of the files, or if you can modify the site, there's really two lines that will help you understand if the ticker is at fault: currentLeftPos = parseInt(ticker1.style.left); currentLeftPos = parseInt(ticker2.style.left); In ticker.js. Try changing those to: currentLeftPos = Math.random(); Or: currentLeftPos = 1; If that makes your problems go away, the ticker is most likely at fault, but nothing crazy is happening here... so if the ticker is at fault it probably just means that clipping or text rendering or something is slow. Another thing to check is whether a longer ticker causes the problem more than a short ticker. -[Unknown]

(In reply to comment #103) > (In reply to comment #101) > > Anyhow, when visiting http://www.fixtureslives.com, I get severe CPU usage, > > which I believe I've tracked down to a "ticker.js" function on the main pages. > > I can just barely reproduce this (my CPU will flirt with 20%, 0% when I hover.) > I think your URL was supposed to be http://www.fixtureslive.com/. > > I tried stripping things out to make a reduced test case, but it became hard > because it seemed like everything I cut out was reducing my CPU usage. > Regardless, the following definitely affect it: > > 1. Removing the search form on the left of the ticker. > 2. Removing the ad (even though I'm using Adblock and don't see it.) > 3. Removing the CSS (this makes the ticker render white on white.) > > Anyway, if you can download a local copy of the files, or if you can modify the > site, there's really two lines that will help you understand if the ticker is > at fault: > > currentLeftPos = parseInt(ticker1.style.left); > > currentLeftPos = parseInt(ticker2.style.left); > > In ticker.js. Try changing those to: > > currentLeftPos = Math.random(); > > Or: > > currentLeftPos = 1; > > If that makes your problems go away, the ticker is most likely at fault, but > nothing crazy is happening here... so if the ticker is at fault it probably > just means that clipping or text rendering or something is slow. > > Another thing to check is whether a longer ticker causes the problem more than > a short ticker. > > -[Unknown] > Hi "Unknown W. Brackets". Firstly, thanks for picking up the URL slip - that's rather embarrassing! It should read: www.fixtureslive.com As to the level of CPU load , I'm sure it depends on the processor. Mine is somewhat long in the tooth but, as the site worked ok with FF2 on the same hardware, I don't really see why this should be so much worse now. I did get in touch with the website tech support and he even reported that he'd got a 50% spike/load with the ticker using FF3. Anyhow, I can't modify the code and was unable to get a complete offline copy but I did look at the site via "Page Source" and although I'm very much a noob and amateur with code in general (and html in particular), I do have some familiarity with VBA, so am half confident with what I was doing. Anyway, I was unable to find the code references that you have referred to, so couldn't try your suggestions. I found code defining the tickertape box attributes... as well as code specifying the actual text being scrolled and, of course, found the references to "ticker.js", "ticker1", "ticker2", etc. Unfortunately, I am a bit out of my depth really here, when it comes to analysing code (it's not my discipline, really) :( With reference to clipping/text rendering, etc, I did wonder whether having ClearType active on my PC could have contributed to the the CPU loading. I turned it off and that made no difference. I would certainly agree that a longer ticker could be more demanding + the message is virtually a series of URL links anyway, so, again, it's not just rendering text and might struggle a wee bit. However, surely, we can't escape the fact that it works ok with FF2, so why are we having difficulties with FF3? My general experiences with FF3 have been that it's definitely quicker rendering pages, which makes this particular problem so noticeable. In fact, it's the first hiccup I've had with FF3 (apart from add-on updates not seeming to install properly when detected during FF3 startup). In addition, given the fact that since IE7 renders the site fine with no CPU load to speak of and FF3 struggles, would that not suggest a browser specific issue? Rgds, Gary

gary, Unknown W. Brackets: Can you please communicate via mail if you have anything further to say to each other? If your comments don't add any new information that help fixing this bug, please refrain from doing so :). I think almost everything has been said in this bug here.

I have a kubuntu 8.04, Pentium D 3.2Ghz with 2 GB RAM and i'm using Firefox 3.0.1. I tried going to the testpage https://bugzilla.mozilla.org attachment.cgi?id=127852 before surfing to the above URL, firefox CPU usage was at 2%. After surfing to the testpage firefox CPU usage increased to 98% (!!!!).

Typo - the address is of course: https://bugzilla.mozilla.org/attachment.cgi?id=127852

The same here. Using Ubuntu 8.10 (Intrepid) last updates and Firefox 3.1 Development The problem also occurs when I'm using Ubuntu 8.10 and Firefox 3.0.2 or 3.0.3

This isn't going to change on the 1.9.0 branch so transfering the wanted nomination to 1.9.1, although I suspect this is too big a change for that release as well.

I scanned through the previous posts to find links that still worked, and on Firefox 3.5b4pre build 20090404052411 here are a few results: http://israelnn.com/ = 0% CPU usage http://www.nrg.co.il/online/HP_0.html = 100% CPU usage http://www.ynet.co.il/home/0,7340,L-8,00.html = 0% CPU usage https://bug142994.bugzilla.mozilla.org/attachment.cgi?id=127852 = 100% CPU usage Intel Q9450 (4x3.0ghz Cores), 4GB RAM, Vista 32bit Ultimate, etc.

Performance problems on different pages should only be in the same bug if profiles show they are caused by the same underlying code problem. Otherwise they should be filed separately; otherwise the bug report becomes an unusable collection of problems. (We want to have one issue per bug so that we can track the progress of fixing the issue, flag that particular problem for getting into certain releases, etc.; if every "something is slow" problem goes in the same bug report, then we can't do that.) Could somebody split out the issues that still exist into their own bugs and resolve this one?

Hi: Is this bug: https://bugzilla.mozilla.org/show_bug.cgi?id=715452 related to the bug in question? If yes, please make the necessary changes for the former.

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:47.0) Gecko/20100101 Firefox/47.0 BuildID: 20160208030244 I failed to reproduce this bug with the attached testcases. Is this bug still relevant?

What this bug report needs right now is a reduced testcase demonstrating the problem. Many people have posted real webpages (that are very long, with a lot of scripts, with many flash videos running, with a lot of advertisements) which are modified and updated on a daily basis. Many of them are now 404 not found or now do not have any news ticker or DHTML marquee.

Reduced test (with no flash, no script, no advertisements; 1236 bytes) with <marquee>: http://www.gtalbot.org/BugzillaSection/Bug142994-1.html Not-yet-reduced test with DHTML scrolling message (I will work on it later to minimize it): http://www.gtalbot.org/BugzillaSection/Bug142994-2.html Please let me know what your CPU percentage activity is for both tests by specifying your CPU (eg 3GHz), your browser and browser version (preferably a very recent browser version, like a Firefox nightly; eg Firefox/47.0 BuildID: 20160208030244).

Works for me Gerard. First test case: Firefox alone uses 16% CPU. Second test case: Firefox alone uses 10% CPU. Pentium 4 dual core. 2.8 GHZ + 2.79 GHZ. Firefox 43.0.04

(In reply to Gérard Talbot from comment #115) > Reduced test (with no flash, no script, no advertisements; 1236 bytes) with > <marquee>: > http://www.gtalbot.org/BugzillaSection/Bug142994-1.html > > Not-yet-reduced test with DHTML scrolling message (I will work on it later > to minimize it): > http://www.gtalbot.org/BugzillaSection/Bug142994-2.html > > Please let me know what your CPU percentage activity is for both tests by > specifying your CPU (eg 3GHz), your browser and browser version (preferably > a very recent browser version, like a Firefox nightly; eg Firefox/47.0 > BuildID: 20160208030244). hi all win 7 home premium 64bit SP1 firefox 44.0.1 ("firefox.exe *32" - reported by task manager) build ID 20160205155049 Intel Core i5 4670K quadcore @ 3.8GHz Test conditions and tools: - Tested in firefox safe-mode - Test1 and Test2 were run individually and were the only tab open during testing - CPU usage initially checked using OS Resource Monitor CPU tab (CPU field) - eventual readings taken with Process Explorer v16.12 (systinternals.com) using CPU field (CPU usage under process performance tab in select columns) - process explorer CPU column is I believe a percentage of total core usage based on the cycle count of that process (http://forum.sysinternals.com/cpu-usage-differs-from-win10-task-monitor_topic31940.html) - process explorer used because readings seemed specific and consistent - tested with both hardware acceleration enabled and disabled (no change in values) - results below are my estimated average readings over a few mins http://www.gtalbot.org/BugzillaSection/Bug142994-1.html 0.6% (text moving) - occasional spike to 1.6% 0.06% (text paused) http://www.gtalbot.org/BugzillaSection/Bug142994-2.html 1.7% (text moving) - irregular spikes to 2.7% 0.05% (text paused) Regards, Gary

Thank you Robert Lindsay and Gary. One thing I do not know yet is what could be or would be the marquee parameters (scrolldelay, scrollamount and direction values) that would increase the CPU percentage activity in http://www.gtalbot.org/BugzillaSection/Bug142994-1.html and then also the parameters in http://www.gtalbot.org/BugzillaSection/Bug142994-2.html . [ Update! http://www.gtalbot.org/BugzillaSection/Bug142994-3.html (quick draft version!) " any scrolldelay value smaller than 60 is ignored and the value 60 is used instead (...) " So, the initial version of Bug142994-1.html was inaccurate. ] I am also under the impression that both Chrome 48.0.2564.103 and Chrome 50.0.2638.0 create more CPU percentage activity, require more CPU in order to handle both tests, more than both Firefox 44.0.1 and Firefox 47 nightly build. http://www.gtalbot.org/BugzillaSection/Bug142994-2.html is roughly what http://www.nrg.co.il/online/HP_0.html uses, does. It dynamically creates a wrapper (<div id="ticker-wrapper_123456789") around the text to be scrolled (<div id="mivzakim">) and then re-positions very fast its top offset with some calculations so that text moves smoothly. I wish I could get rid of that huge and inefficient jQuery code (jquery-1.7.2.min.js) and streamline that test...

(In reply to Gérard Talbot from comment #118) > http://www.gtalbot.org/BugzillaSection/Bug142994-3.html (quick draft > version!) > " > any scrolldelay value smaller than 60 is ignored and the value 60 is used > instead (...) > " Link to above constraint: https://developer.mozilla.org/en-US/docs/Web/HTML/Element/marquee#Attributes Also, HTML5, section 15.3 Requirements for implementations, section 15.3.2 The marquee element https://html.spec.whatwg.org/multipage/obsolete.html#the-marquee-element-2 " If the [marquee] element does not have a truespeed attribute, and the [scroll]delay value is less than 60, then let [scroll]delay be 60 instead. "