473580 - Cpu usage spikes when you use a java applet and open/use another tab.

Status: RESOLVED FIXED

(Core Graveyard :: Plug-ins, defect, P2)

Description

[Danial Horton]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2

When you open a Java applet, and then change tabs, the cpu usage of java.exe reaches 100% on a single core of a cpu.

The issue, however only occurs if you have actually clicked inside the applet.

Reproductions can be made at the applet in the site linked, or at pogo.com, habbo's hotel and various other sites.

Reproducible: Always

Steps to Reproduce:
1. Install Sun Java 6 update 10 or higher (12 beta if running Vista)
2. Navigate to a site with a java applet, such as pogo.com, or the site linked and click inside the applet, (might need to click the text input box, or a button)
3. Open a new tab and switch to it

Actual Results:  
Java.exe starts using 100% of the cpu, or a core on the cpu.
(Tested and not reproducible on IE 7)

Expected Results:  
The applet does not use 100% cpu when changing tabs (it doesn't when its in the applets tab)

To access the Test Url you may need a UN/PW

I've generated a limited test account for testers
UN:MozTest
PW:bugtest

Comment 1

[Danial Horton]

I used to open the chat up fine in Fx 2.0, so thats why i think its a 3.x+ bug.

Comment 2

[David Quintana]

Confirmed on
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090113 Shiretoko/3.1b3pre (.NET CLR 3.5.30729) ID:20090113033008
and
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.2a1pre) Gecko/20090114 Minefield/3.2a1pre (.NET CLR 3.5.30729) ID:20090114034711

in both cases java.exe runs on jumps to 48-49% (96-98% of one core in my dual-core pc).

Comment 3

[Danial Horton]

Ah, i also confirmed it on
Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090113
Shiretoko/3.1b3pre (.NET CLR 3.5.30729) ID:20090113033008

though my minefield isn't up to date.

Comment 4

[Ria Klaassen (not reading all bugmail)]

I think I see something like this too. It doesn't seem related to JIT.

Comment 5

[Danial Horton]

nope, its not, it happened in 3.0 as well.

my second profile has JIT off for consistency testing.

Comment 6

[Ria Klaassen (not reading all bugmail)]

Regression range is http://hg.mozilla.org/mozilla-central/pushloghtml?startdate=2008-11-02+00%3A00%3A00&enddate=2008-11-02+22%3A00%3A00
Possibly caused by Bug 458928.

Comment 7

[Benjamin Smedberg]

roc, can you take a look/triage this? It's a regression from bug 458928 (drawWindow not rendering flash)

Comment 8

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

Almost certainly due to the tab preview code calling drawWindow to draw the plugin.

I assume this doesn't happen with Flash, so we're probably triggering some bug in the plugin.

Comment 9

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

We can probably turn off drawWindow rendering just for Java. Should we do that?

Comment 10

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

I don't think we should block on a real fix for this. We could block on just disabling drawWindow tickling Java.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

Can you file that followup bug, roc?

Comment 12

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

I'd rather use this bug for it.

Comment 13

[Benjamin Smedberg]

In that case, who should own it?

Comment 14

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

I'll put it on Zack's plate. It should be a simple fix in nsObjectFrame, once we've found the API to detect whether the plugin is Java.

Comment 15

[Zack Weinberg (:zwol)]

Pretty easily reproducible in a nightly on Windows.  I wonder, though, why are we running the tab-switch-preview code when all I did is click on some other tab?  Shouldn't it only fire when the preview images are needed?

Also, there's already code in nsObjectFrame to condition behavior on the name of the plugin - how specific do we want to be here?  The thing one currently gets from Sun by default on Windows XP calls itself "Java(TM) Platform SE 6 U11"; I would imagine the bug affects all versions of Java from Sun to date but perhaps not others.

Comment 16

[Benjamin Smedberg]

Because generating all the previews when you click the tab-switch button makes that dialog appear very slowly. Regenerating the previews when we switch tabs is a relatively cheap optimization for TTabswitchOpen

Comment 17

[Zack Weinberg (:zwol)]

Attachment: disable painting objectFrames that are sun java from drawWindow

This patch does indeed make the CPU spike go away.

It's inside #ifdef XP_WIN.  I'm inclined to leave other platforms alone as long as we don't have a report of the same problem there.

Also note that no future version of Sun Java is going to be trusted either.  I suppose we can fix that if and when someone tells us that X future version definitely doesn't fail the same way.

Comment 18

[Zack Weinberg (:zwol)]

Comment on attachment 360219 [details] [diff] [review]
disable painting objectFrames that are sun java from drawWindow

guessing at reviewer :-/

Comment 19

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Comment on attachment 360219 [details] [diff] [review]
disable painting objectFrames that are sun java from drawWindow

Looks fine to me; jst, is this ok?  Can we let the sun guys know about this bug as well?

Comment 20

[Johnny Stenback (:jst)]

Kenneth, do you have any thoughts on this? Does the string we're matching on in the patch look ok to you? I'm happy to take this patch on our end, assuming this doesn't seem like it would cause problems on your end.

Comment 21

[Kenneth Russell]

It sounds like we aren't validating the region of the in-browser window in the new Java Plug-In upon receiving a draw event and need to. We've seen similar issues in IE in the past. The workaround patch seems fine, assuming that applets continue to draw properly. We should fix this in the Java Plug-In regardless.

Comment 22

[Johnny Stenback (:jst)]

Zack, looks like this is ready to land, can you take care of that, or do you need help?

Comment 23

[Zack Weinberg (:zwol)]

I still don't have commit privs; looks like I forgot to tag for checkin.

Comment 24

[Johnny Stenback (:jst)]

Fix pushed to trunk and 1.9.1.

Comment 25

[Robert Kaiser]

(In reply to comment #24)
> Fix pushed to trunk and 1.9.1.

You pushed onto the COMM_20090224_RELBRANCH on 1.9.1 instead of the default "branch".

Comment 26

[Serge Gautherie (:sgautherie)]

(In reply to comment #25)
> You pushed onto the COMM_20090224_RELBRANCH on 1.9.1 instead of the default
> "branch".

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/8f0f44a9fa81

Comment 27

[Johnny Stenback (:jst)]

Duh, thanks for fixing. Checked into the right place now.

http://hg.mozilla.org/releases/mozilla-1.9.1/rev/524c18a6103a

Comment 28

[Ashley Bischoff (blog at handcoding.com)]

If there was still concern about CPU usage of plugins on background tabs, bug 309691 (re:plugin idle-event throttling for inactive tabs) may also offer some ideas.