From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.4+) Gecko/20010926 BuildID: 2001092610 Recently [for the lack few weeks of nightly builds], if I visit a site that uses the Flash plugin, mozilla slows to a *crawl* and just about hangs up completely. Two sites that demonstrate this for me are: http://www.play247.com http://www.lcegroup.co.uk I'm using the current 5.0r52 Flash player. One might think this a problem with the player, except: o It worked fine a few weeks ago o It works fine in 4.x I am seeing an error loading the player class file; see bug 101871, which also started a few weeks ago, but this may be coincidence. The player does appear to work (animations appear etc), but the browser becomes unusable within minutes. Reproducible: Always Steps to Reproduce: 1.visit one of the listed sites 2.try and continue using the browser (within the sites). 3.
works fine on W2K 2001092503 - Shockwave Flash 5.0 r41
I note that when the page first comes up, all is well. As soon as the animations get loaded, mozilla's cpu usage goes to 100%, and it becomes almost unusable. Clicking on anything takes minutes to react, and after that it more or less just hangs up completely. I realise we're a bit short of detail here, but not sure what more I can provide.
Can't reproduce problem on Solaris with Mozilla 0.9.4 build 2001092610 by going to either site. My browser is perfectly responsive.
I lied, Seems you jave to leave your browser on that page for a minute or two. Couldn't reproduce with http://www.play247.com, but can with http://www.lcegroup.co.uk which takes you to http://www.londoncameraexchange.co.uk/Ice2.html Mozilla starts gobbling up all CPU time.
It takes a few minutes to load the animations from the play247 site; whilst they're loading all is fine, but once they start to play, that's when it goes downhill. Reproducible everytime for me.
I can confirm this. I'm using Mozilla nightly 2001101210 on a sparc ultra 5 running solaris 8, with flash plugin "Shockwave Flash 5.0 r52". Went to www.play.com (play247.com just redirects to play.com). The page contains four separate SWF objects, each of which plays continuously. Once the flash animations begin, mozilla becomes unresponsive. The animations play at what appears to be normal speed, but mozilla doesn't respond to button clicks or X windows events. E.g. if a mozilla window is minimized and restored, mozilla won't repaint it. Basically, it appears that mozilla is giving all of its processing time to Flash, leaving nothing for mozilla itself. I reduced www.play.com to a testcase containing only the OBJECT tags for the four flash animations, and then tried loading the page with some of the objects commented out. On my host, moz behaves well with one object active, becomes sluggish with two, and very sluggish to nonresponsive with three or more. A more powerful computer might do better.
same problem as in bug 99361
I'm seeing this with linux, mozilla 0.9.7 and the flash 5.0r47 plugin too. This may or may not be related to other problems I'm having with the plugin; it hangs mozilla on other flash-using sites too (like http://www.flash.com). In the case of the lcegroup.co.uk mozilla starts to eat as much cpu as it can; the other site works just fine. Maybe platform/os should be changed to all/all ?
I'm seeing the same problem with Mozilla 0.9.7, flash 5.0r47.
--- Mass reassigning Unix bugs to serge ---
Assignee: av → serge
I have no idea what we can do in mozilla code to improve flash performance ;) the simple comparison of cpu% for flash 5.0 r47 plugin in netscape 4.78 and mozilla 2002-02-02 gives me roughly the same % on test case attachment 53384 [details] or 7up.com, of course % depends on speed of cpu I'm going to close this as WONTFIX
*** This bug has been marked as a duplicate of 99361 ***
Status: NEW → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → DUPLICATE
mass duplicate verifications . For filtering purposes, pls use keywd "massdupverification"
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.