User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060529 SeaMonkey/1.5a Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060529 SeaMonkey/1.5a When the content of the web pages at http://www.investor.bg is displayed in several tabs (or different windows - it doesn't matter) after the content is loaded and displayed (Status line = 'Done') CPU stays at nearly 100%. If I close some of the tabs the CPU usage drop to some 10-15%. My CPU is Intel P4 2.8GH with 1MB Cache. And when this happens that FANs in the computer increase their speed and this causes awful noise. I am using the lates trunk version of Firefox. I also update to the Public Beta version 9 of Flash Player (about:plugins shows Shockwave Flash 9.0 r2). Reproducible: Always Steps to Reproduce: 1. Go to http://www.investor.bg 2. Open three or more of the news in new tabs The news are in 'Bulgarian' language with windows-1251 encoding but this shouldn't matter. You can use the following URLs for the additional tabs (windows) http://www.investor.bg/?id=38298 http://www.investor.bg/?id=38303 http://www.investor.bg/?id=38304 http://www.investor.bg/?id=38308 Actual Results: After the pages load the CPU usage is very high (between 50 and 100% ). Expected Results: Very low CPU usage to be used after the page is displayed as is the case in Internet Explorer 6. If I open more pages then the browser sometimes hang for 2 to 30 minutes, before it get responsive again (before allowing me to close some page or tab). I have to sometimes kill the process to be able to do anything with my computer. This is why I classify this as a critical severity. The same/similar behaviour is observed with Firefox 1.5.0.4 and with Seamonkey 1.5a1 (nightly builds). Using process explorer I see there are two thread which do many context switches firefox.exe and winmm.dll (the numbers are about 1900 for firefox.exe+0x5102e6 and 1750 for WINMM.dll+0x927f for the default refresh interval which seems to be around 2 seconds) my WINMM.dll is version 5.0.2161.1. The status of the WINMM.dll thread is 'Wait:UserRequest'. The status of the firefor.exe thread is 'Ready'.

Forgot to say the build actually used to reproduce was: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20060612 Minefield/3.0a1 and the computer has 1GB RAM.

would somebody with confirm privileges mark this bug as confirmed (after testing it)?

This is the most CPU intensive Flash from the URL. IE also consumes a lot of CPU cycles, however, when IE is minimized the CPU usage drops to 0. Maybe Firefox could optimize plugin behaviour in a simiral manner. Tested with ff1.5.0.4 on win2k with Shockwave Flash 7.0 r19

If I remove wmode="opaque" then the CPU usage drops to 0 when FF is minimized or the tab with the flash is hidden. Tested with Flash 7.0 r19 and Flash 8.0 r22

I'm cc'ing Michelle as I think this might be a Flash issue. Just tested with Flash 9.0 r7 with both ff1.5.0.4/2.0a3/latest trunk and Opera 8.54 and the problem described in comment 6 persists. CPU usage does not go down when ff is minimized/tab hidden.

Thanks for the bug report; the Flash Player team will investigate this issue.

Firefox 1.5.0.7 with Flash 9.0.16.0 on Windows XP: Open testcases % CPU 0 0 1 15 2 30 3 45 4 60 It doesn't matter whether the tabs or window is hidden. Closing the testcase tabs and opening the investor.bg uris in place of them, CPU went from 22 to 45 as i checked them and then to 98 as switching to another tab became unresponsive. I was still able to middle-click the tabs away.

(In reply to comment #8) > Thanks for the bug report; the Flash Player team will investigate this issue. > Any progress with this issue? Michelle will you assign this to yourself or to someone else ? Firefox is becoming useless on pages with flash animations. I also suspect memory leaks but that's another story. Has the Adobe acquisition changed something?

(In reply to comment #8) > Thanks for the bug report; the Flash Player team will investigate this issue. > Hi Michelle, in behave of our readers of mac-tipps.de I would like to ask whether your Flash Player team has any news regarding the CPU-load-bug? Thanx an best regards... Michael Huelskoetter mac-tipps.de

A suggestion to the bug reporters: Try reporting the flash bug here (in case Michelle is on some vacation or not on the job and that's why he is not responding) http://www.adobe.com/cfusion/mmform/index.cfm?name=wishform I used it to report the problem in bug 334322

Michelle is away til I think January or later. Perhaps she is monitoring, but I know others at adobe are aware of these bug reports and I am surprised no one from adobe has commented here since. I have corresponded with one.

It seems to me like a duplicate of bug 207200

(In reply to comment #14) > It seems to me like a duplicate of bug 207200 depends, among other things: * is this bug 341380 OS=ALL? * does it date back to the same cause? http://www.investor.bg/ FF for me pushes same cpu whether in foreground or background tab. It's interesting that, unlike the the flash memory bugs, I don't see this cpu issue using seamonkey trunk - it doesn't consume extra cpu if http://www.investor.bg/ with in background.

With seamonkey trunk 2006120908 6 tabs with the attached testcase saturate my CPU. You open the testcase link in 6 tabs, then click through the tabs to initialize them, and then mozilla takes 95% CPU. The interesting thing is that the other bug 342810 with the memory leak doesn't show up in my case.

I just tested this on Minefield trunk build on Linux with flash plugin 7.0.69 and didn't notice excessive CPU usage, nor memory leaks. This was on openSUSE 10.2. In fact when no flash animation is visible the CPU usage is near zero. So it is not OS=ALL.

We (the Flash Player team) have a fix for this bug for an upcoming Flash Player release. I will update this bug when that player is released. Thanks for your patience.

Michelle in comment #18: > We (the Flash Player team) have a fix for this bug for an upcoming Flash Player > release. I will update this bug when that player is released. Thanks for your > patience. Michelle, was this fixed in flash 9?

improved summary. also: bug 238935 dates to rv:1.7b Gecko/20040320 Firefox/0.8 bug 267599 dates to rv:1.8a5 Gecko/20041101 Firefox/0.9.1+

(In reply to comment #18) michelle: did the bug you fixed only apply to windows?

This Flash Player bug fix has not yet been released. I will update this bug when it is, I promise. And, the bug fix affects both Windows and Mac.

OS -> All updated summary

michelle: does 9.0 r45 which was released on 4/12 contain the fix?

>does 9.0 r45 which was released on 4/12 contain the fix? No, it doesn't. The fix will be in a later release.

Marc comment #26 > michelle: does 9.0 r45 which was released on 4/12 contain the fix? http://www.adobe.com/support/documentation/en/flashplayer/9/releasenotes.html states "Fixes and improvements in Flash Player 9.0.45.0: Support for Creative Suite 3"

Related to bug 34887, "Need to optimize painting of overlapping opaque frames"?

(In reply to comment #29) > Related to bug 34887, "Need to optimize painting of overlapping opaque frames"? related in what specific way with regard to opaque? this bug mentions nothing about overlap. and bug 34887 mentions nothing about flash.

This bug should be fixed with Flash Player 9 Update 3. A beta version, 9.0.60.120, can be downloaded here: http://labs.adobe.com/downloads/flashplayer9.html

Yes, the problem seems to be fixed with Flash Player 9,0,60,120. That means that when a flash is not visible it doesn't consume much CPU. A question to Michelle: does that mean that if flash is not visible it will not run (e.g. if it runs a repeating process with a timer will it still process the event), or is just the display functionality skipped ? Questions to others: Should this bug be marked as 'Fixed' since no change was done in mozilla code, or should it be marked as WORKSFORME, or INVALID ? Where should it be documented the required flash version?

(In reply to comment #32) > Where should it be documented the required flash version? feel free to discuss this in bug 271559