142994 - Dynamic "newsticker" [DHTML scrolling message, javascript marquee] causes high CPU usage

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[emmet]

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:

Comment 1

[guanxi]

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

Comment 2

[Boris Zbarsky [:bzbarsky]]

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

Comment 3

[Phil Schwartau]

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.

Comment 4

[Phil Schwartau]

Attachment: Reduced testcase (JavaScript scrolling text only)

Comment 5

[Phil Schwartau]

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 -

Comment 6

[emmet]

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?

Comment 7

[Laura Krietemeyer]

Changing QA Contact

Comment 8

[Phil Schwartau]

[e-mail]: 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 - 

Comment 9

[Phil Schwartau]

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%

                                                                                      
[e-mail]: are you still having the CPU problem?

Comment 10

[Boris Zbarsky [:bzbarsky]]

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>

Comment 11

[Phil Schwartau]

Boris: thanks! 

I have filed Evangelism bug 143301 on this site:
"CSS mistake makes scrolling text invisible"

and cc'ed both you and [e-mail] -

Comment 12

[emmet]

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

Comment 13

[Peter 'vt100' Schwindt]

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

Comment 14

[darren kruse]

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.

Comment 15

[darren kruse]

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

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

Comment 16

[darren kruse]

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.

Comment 17

[Markus Hübner]

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

Comment 18

[S. Grundner-Culemann]

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

Comment 19

[Markus Hübner]

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

Comment 20

[Zibi Braniecki [:zbraniecki][:gandalf]]

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

Comment 21

[Markus Hübner]

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?

Comment 22

[Markus Hübner]

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

Comment 23

[Markus Hübner]

reassigning to default layout owner.

Comment 24

[Max Kanat-Alexander]

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

Comment 25

[Max Kanat-Alexander]

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

Comment 26

[Boris Zbarsky [:bzbarsky]]

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

Comment 27

[Max Kanat-Alexander]

Attachment: Testcase: Slows Moz, but not IE

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.

Comment 28

[Max Kanat-Alexander]

Attachment: Testcase: Slows Moz And 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

Comment 29

[Frank Wein [:mcsmurf]]

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

Comment 30

[Boris Zbarsky [:bzbarsky]]

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

Comment 31

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 32

[Boris Zbarsky [:bzbarsky]]

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.

Comment 33

[Boris Zbarsky [:bzbarsky]]

Attachment: Profile

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

Comment 34

[Max Kanat-Alexander]

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

Comment 35

[Boris Zbarsky [:bzbarsky]]

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

Comment 36

[boozai]

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?

Comment 37

[Gérard Talbot]

> 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

Comment 38

[Gérard Talbot]

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.

Comment 39

[Markus Hübner]

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

Comment 40

[Markus Hübner]

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

Comment 41

[Steffen Wilberg]

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

Comment 42

[Steffen Wilberg]

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.

Comment 43

[Gérard Talbot]

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

Comment 44

[Markus Lindström]

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

Comment 45

[Gérard Talbot]

> 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

Comment 46

[Gérard Talbot]

Blocking bug 21762

Comment 47

[Noam Tamim]

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.

Comment 48

[Kyle Secord]

Tested: WinXP Pro SP2 - Deer Park Alpha 2 - CPU Time: 0%
PIII - 700mhz

I could not recreate this bug.

Comment 49

[Markus Lindström]

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

Comment 50

[Gérard Talbot]

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

Comment 51

[Gérard Talbot]

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.

Comment 52

[jhony]

(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:    [e-mail]
maybe they can offer some insight

Comment 53

[lvm]

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

Comment 54

[Rimas Kudelis [use needinfo to ping]]

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.

Comment 55

[Wayne Woods]

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

Comment 56

[Diego]

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

Comment 57

[Daniel Veditz [:dveditz]]

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.

Comment 58

[Roscoe Primrose]

(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

Comment 59

[Wayne Woods]

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. 

Comment 60

[Ronald Tilby]

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

Comment 61

[Roscoe Primrose]

(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

Comment 62

[Robert Lindsay]

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.

Comment 63

[Wayne Woods]

(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!

Comment 64

[Niro]

(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?

Comment 65

[Robert Lindsay]

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

Comment 66

[Gérard Talbot]

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

Comment 67

[Boris Zbarsky [:bzbarsky]]

Need to retest when reflow branch lands.

Comment 68

[Robert Lindsay]

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

Comment 69

[Wayne Woods]

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

Comment 70

[Ryuichi KUBUKI]

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

Comment 71

[Ryuichi KUBUKI]

(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]

Comment 72

[Martin Jürgens]

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

Comment 73

[Matthias Menzel]

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

Comment 74

[Ryuichi KUBUKI]

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

Comment 75

[Brian Crowder]

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.

Comment 76

[Wayne Mery (:wsmwk)]

(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

Comment 77

[Ryan VanderMeulen [:RyanVM]]

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

Comment 78

[ms]

Here another page which make Firefox consume 100% forever

http://cadivi.gov.ve/

then click on [Usuarios Registrados]

Comment 79

[Kirk M]

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? 

Comment 80

[Kirk M]

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? 

Comment 81

[Kirk M]

Sorry for the double post. New to Bugzilla

Comment 82

[Roman R.]

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

Comment 83

[Kirk M]

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.

Comment 84

[Roman R.]

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.

Comment 85

[Gérard Talbot]

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

Comment 86

[Kirk M]

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.

Comment 87

[Kirk M]

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

Comment 88

[Ted Sbardella]

(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

Comment 89

[Jim Jeffery not reading bug-mail 1/2/11]

(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

Comment 90

[ms]

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.

Comment 91

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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.

Comment 92

[Kirk M]

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

Comment 93

[Brian Crowder]

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.

Comment 94

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

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

Comment 95

[Sven E.]

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

Comment 97

[Joel]

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.

Comment 98

[Priit Uring]

<<<- 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?

Comment 99

[Glen A.]

http://www.buycomputers.co.za/default.htm

99% CPU on Firefox 3.0 (when moving)

Comment 100

[Martijn Wargers (dead)]

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

Comment 101

[gary]

(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

Comment 102

[Martin Jürgens]

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.

Comment 103

[Unknown W. Brackets]

(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]

Comment 104

[gary]

(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

Comment 105

[Frank Wein [:mcsmurf]]

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.

Comment 106

[Joel]

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% (!!!!).

Comment 107

[Joel]

Typo - the address is of course:

https://bugzilla.mozilla.org/attachment.cgi?id=127852

Comment 108

[Gilberto Olimpio]

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

Comment 109

[Daniel Veditz [:dveditz]]

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.

Comment 110

[Brian Carpenter [:geeknik]]

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.

Comment 111

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

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?

Comment 112

[Vikram Kamath]

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.

Comment 113

[Jan Sonntag]

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?

Comment 114

[Gérard Talbot]

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.

Comment 115

[Gérard Talbot]

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

Comment 116

[Robert Lindsay]

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

Comment 117

[gary]

(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

Comment 118

[Gérard Talbot]

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

Comment 119

[Gérard Talbot]

(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.
"

Comment 120

[Andrei Purice]

Marking this as Resolved > Worksforme since the high CPU usage is not occurring anymore using Release 93.0, Beta 94.0b2 and latest Nightly 95.0a1 (2021-10-07) on Windows 10.
If anyone else is able to reproduce it please re-open the issue or file a new one.