230783 - Apparently still animating plug-in content when browser is in the background or tab is not displayed

Status: RESOLVED EXPIRED

(Core Graveyard :: Plug-ins, defect)

Description

[Oscar van Vliet]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007

When I have IHT.com open, which tends to have some pretty fancy animated GIFs
and/or flash ads, Mozilla continues to eat a pretty sizeable chunk of processing
time even when it is in the background. This can hit up to 30% (on peaks).


Reproducible: Always

Steps to Reproduce:
1. Open a few websites with flash content or animated images.
2. Make sure the webpage isn't still loading or click stop.
3. Open another app (full window size) and start working.
4. Open Task Manager and keep an eye on Mozilla resource use.

Actual Results:  
Mozilla was using processor time.

Expected Results:  
Kept quiet and not spend my processor's time on things I am not looking at

I'm using a Compaq Evo N1020v (P4 @ 2.4 GHz, 256 MB RAM) and running WinXP.

Mozilla is using the basic English region/language pack and running the Modern
theme.

This problem may be related to bug 140934. I'm thinking that everything that
gives visual output or relies on user interaction should be suspended when
Mozilla is in the background. I can't think of another explanation for the heavy
CPU usage right now.

P.S. I know this is a bug on an old Mozilla version - apologies, but I haven't
seen stuff coming around that looks like this. I'll see if this is present in
1.6 final when it comes out.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> I'm thinking that everything that gives visual output or relies on user
> interaction should be suspended

Plugins are separate processes; they can't be suspended, really (they even draw
directly to the graphics card a lot of the time).

> when Mozilla is in the background. 

There is no reliable way to detect this.

Not a DOM events issue and filed before (probably resolved).

Comment 2

[Oscar van Vliet]

>> I'm thinking that everything that gives visual output or relies on user
>> interaction should be suspended when Mozilla is in the background. 

>There is no reliable way to detect this.
>Not a DOM events issue and filed before (probably resolved).

I am very surprised when you say that you can't detect if (for instance) no
Mozilla window is in focus or not.

Any idea what component I might move this too, then? I actually tried a search
but couldn't find a dupe.

Comment 3

[R.K.Aa.]

bug 120154 is related

Comment 4

[Oscar van Vliet]

Moving to Core, as it looks like it is underlying/DOM related code.

Comment 5

[Steven Michaud [:smichaud] (Retired)]

A better example of these problems is http://www.rogerdean.com/ (which
contains a Flash object that's a heavy consumer of CPU-cycles -- I got
it from Bug 235968).  It's better because it's so extreme :-)  Thanks
to this it's easy to compare the behavior of any of the Mozilla-family
browsers to Safari ... and to see that Safari gets things right, while
the Mozilla-family browsers don't.  If Safari can do it, so (you'd
think) can the Mozilla-family browsers.

(It's possible that the problems shown in my tests are Flash-specific.
Even if they are, they're worth correcting.  But like ovvldc, I
suspect they're more general.)

The 500-pound Flash object that I used in these tests is at the top of
the rogerdean page -- Roger Dean's name in an outline font with
color-cyclying inside the letters.  I tested on Mac OS X 10.3.6.  My
Mac is a dual-1-Ghz G4.

CPU-Consumption in Foreground and Background

Open http://www.rogerdean.com/ in Safari and then run 'top' in a
Terminal window.  Arrange the windows so that neither overlaps the
other (this puts the test at one extreme, or edge-condition).

I find that when the Safari window is active (in the foreground),
Safari's CPU-usage (according to top) bounces around between about 20%
and about 35% -- depending (presumably) on where you are in the
color-cycling.

But when the Terminal window is active, Safari's CPU-usage bounces
around between about 7% and about 13%.

(I admit this result is a bit puzzling.  The Flash object is still
visible and still color-cycling.  But both figures represent Flash
activity almost exclusively -- when I go "back" to Safari's home page
in the same window, CPU-usage falls to between 0% and 1%.  The Flash
object must be getting fewer CPU-cycles when the window is in the
background, even though this difference has no visible effect.)

Quit Safari and open http://www.rogerdean.com/ in (say) Firefox 1.0.
Arrange things so that the Firefox and Terminal windows don't overlap.

Which window is active makes no difference.  Firefox's CPU-usage
bounces around between about 25% and about 40%.  (At its own home page
(the Google page), Firefox's CPU-usage is between 1% and 2%.)

CPU-Consumption in Foreground and Minimized

Set up as above.  But this time minimize the browser window and
restore it, and observe the differences.

With the rogerdean window minimized, Safari's CPU-usage falls to 0%.

With Firefox's rogerdean window minimized, its CPU-usage varies
between about 25% and 30%.  Clearly there's _some_ difference -- my
guess is that the color-cycling gets suspended.  But not as big a
difference as with Safari.  And not enough of a difference.

(I get similar (though not identical) results with Mozilla 1.7.3 and
Camino 1.8.2.  Give Camino a few minutes to settle down after you open
rogerdean in its window -- the CPU-usage can bounce around quite
wildly at first.)

Comment 6

[Steven Michaud [:smichaud] (Retired)]

I reran my tests on Windows 2000 (on an old dual-CPU Dell Pentium II
450Mhz) ... and wasn't able to reproduce the Mozilla-family-browser
problems (and discrepancies) that I saw on OS X.  So they're probably
Mac-specific.  But they're still worth some attention.

I used the latest available version of the Flash plugin (7.0.19.0), as
I had on the Mac (7.0 r24).

This time the "other browser" (playing the role of Safari) was
Internet Explorer 5.5 (with the latest patches).  On the
Mozilla-family side were Mozilla 1.7.3 and Firefox 1.0.  My CPU-load
monitor was the Windows Task Manager.

Putting the browser window in the foreground or in the background made
no difference with any of the browsers.  But in all of them,
minimizing the browser window reduced CPU-usage to its "background
level" of about 0%.

Comment 7

[Steven Michaud [:smichaud] (Retired)]

One more twist on the rogerdean business:

On both Windows 2000 and Mac OS X 10.3.6, I did the following with
each of the Mozilla family of browsers:

In a single browser window I opened two tabs -- on containing the
browser's home page and the other containing
http://www.rogerdean.com/.

On Windows, switching away from the rogerdean tab caused the browser's
CPU-usage to fall to about 0%.  But on the Mac it always stayed the
same.  Clearly the Mac behavior is wrong and the Windows behavior
right.

Comment 8

[Oscar van Vliet]

The fact that GIF pictures keep eating CPU when invisible is covered in bug
120154. This leaves other media types (like Flash) for this bug. I changed the
summary to reflect this.

I changed Hardware/OS from PC/Win XP to All/All to reflect that this is
happening on the Mac as well. Though the Windows version seems to have made some
progress, so maybe this is restricted to Mac/OSX now. I don't have access to a
testing machine at the time of writing.

Comment 9

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 10

[Gervase Markham [:gerv]]

This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.