887129 - On Firefox 22.0, GMail constantly uses CPU time, reducing battery life significantly

Status: RESOLVED WORKSFORME

(Firefox :: Untriaged, defect)

Description

[Simon Broenner]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:21.0) Gecko/20100101 Firefox/21.0 (Beta/Release)
Build ID: 20130511120803

Steps to reproduce:

Install FF22
Open GMail


Actual results:

CPU usage sits at 1-3%, power consumption at 7W.


Expected results:

CPU usage at 0% almost constantly, power consumption right below 6W (this was the behavior on FF21). With my laptop's big 9-cell battery, I'm seeing a battery life drop of almost 2 hours...

Comment 1

[Loic]

Could you test with a fresh profile, please.
https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles

Be sure you have a good parameter to notice the issue (like CPU use or something like that).

Comment 2

[Simon Broenner]

Also happens on a new profile. Both the increased CPU usage and the subsequent higher power drain (taken from Thinkvantage Power Manager on my Thinkpads) are present with a new profile.

Comment 3

[Loic]

Ok, so maybe there is a possible regression in FF22.

As you're able to reproduce the issue easily, could you install and use the tool mozregression (see http://harthur.github.io/mozregression/ for details) to find a possible regression range, please.

FF22 nightlies started in Feb. 2013: mozregression --good=2013-02-01
For each nightly build automatically downloaded, a clean profile will be created (no need to use your current profile as you're able to measure the CPU use from a fresh profile).

Comment 4

[Simon Broenner]

Cool tool, downloading right now. Which nightly is equivalent to FF21 final (so I can use that as my known "good" date...)?

Comment 5

[Loic]

None, after Nightly, there is Aurora, then Beta, then Release. But you don't need that, every new code is added into Nightly and it's in these builds we need to find the regression.

Comment 6

[Simon Broenner]

OK. I'm currently down to somewhere between 2013-04-18 and 2013-05-22... still going though, the FTP server is a bit slow :(

Comment 7

[Simon Broenner]

As far as I can tell, the issue started to occur in nightly 2013-05-04. 2013-05-03 does not yet exhibit the issue.

Comment 8

[Paul Silaghi, QA [:pauly]]

Please post the result (the pushlog) from the end of your mozregression work.

Comment 9

[Simon Broenner]

Hi there, sorry it took me so long to get back to you, this slipped out of my mind until I realized I was still on FF21 yesterday...

Output from Mozregression:

"Mozilla tools directory: C:\mozilla-build\"

simon@SIMON-THINKPAD ~
$ mozregression --good=2013-05-01 --bad 2013-05-10
Downloading nightly from 2013-05-05
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): bad
Downloading nightly from 2013-05-03
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): good
Downloading nightly from 2013-05-04
Installing nightly
Starting nightly
Was this nightly good, bad, or broken? (type 'good', 'bad', 'skip', 'retry', or 'exit' and press Enter): bad


Last good nightly: 2013-05-03
First bad nightly: 2013-05-04

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=b35170667a2f&tochange=69008b1fd6eb

do you want to bisect further by fetching the repository and building? (y or n) n

simon@SIMON-THINKPAD ~
$

I can't make sense of the pushlog though... hope that's the right thing there... I was expecting something along the lines of a log of the mozregression activity.

Comment 10

[Paul Silaghi, QA [:pauly]]

The pushlog contains all the bugs pushed between the last good/first bad nightly. One is responsible for your problem.
I can't figure which one, let's see if someone can help.

Comment 11

[Loic]

It could be related to HWA.
Simon, could you test with HWA disabled, please.
https://support.mozilla.org/en-US/kb/forum-response-disable-hardware-acceleration

If it's better, copy/paste the section "graphics" from the page about:support.

Comment 12

[Simon Broenner]

Hi, it's definitely not HWA acting up, since I've had that disabled from day one.

Graphics section:

https://dl.dropboxusercontent.com/u/7086491/pictures/graphicssectionaboutsupport.PNG

Comment 13

[Loic]

Is it posisble to test with HWA enabled, please (restart FF to apply).
So we'll see if it's an issue with HWA or not.

Comment 14

[Simon Broenner]

It's the same with HWA on, and the nightlies (both good and bad) were run with HWA on (default settings).

Comment 15

[Josh Matthews [:jdm]]

If anyone else can reproduce this and narrow the mozilla-inbound window, that would be swell.

Comment 16

[Simon Broenner]

For repro: Make sure that you're not running Flash content - as soon as you do this, Firefox's idle CPU usage jumps by a huge amount, masking the issue I'm reporting here.

Comment 17

[Simon Broenner]

Still present in FF23.

Comment 18

[Loic]

Could you try with asm.js disabled, please.
about:config > javascript.options.asmjs = false (restart maybe)

Comment 19

[Simon Broenner]

Seems to help. Any idea why?

Comment 20

[Tobias B. Besemer [:BesTo] (QA)]

I was searching for an gmail bug because I recognized that when I have gmail open in the background FF slows down rapidly.

At first I was thinking this is an sessionstore bug, too. But gmail seems to don't use much of them.

I tried: about:config > javascript.options.asmjs = false (restart maybe)

I can't say if FF now need less CPU, but my FF seems to be twice as fast as before !!!
Even if there is no gmail open! Also the session restore of the browser is much faster !!!

I use an Win7 64bit with:
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:26.0) Gecko/20100101 Firefox/26.0 ID:20131114085019 CSet: 2328244402b1
and the NoScript Extension on the most pages activated.
And no Plugins activated.

I found two bugs in bugzilla that seems to describe alike problems:
Bug 765503 - Opening Gmail Causes Hanging of Mozilla Firefox 13.0
Bug 779586 - Can no longer use Gmail with Firefox browser after change to Google Plus

Comment 21

[Florian Bender]

(In reply to Tobias B. Besemer from comment #20)
> I tried: about:config > javascript.options.asmjs = false (restart maybe)
> 
> I can't say if FF now need less CPU, but my FF seems to be twice as fast as
> before !!!
> Even if there is no gmail open! Also the session restore of the browser is
> much faster !!!

OdinMonkey should not affect the performance of Firefox, please do some test runs on a clean profile and file a new bug (worst case it gets duplicated) if the issue persists.

Comment 22

[Luke Wagner [:luke]]

(In reply to Florian Bender from comment #21)
> OdinMonkey should not affect the performance of Firefox, please do some test
> runs on a clean profile and file a new bug (worst case it gets duplicated)
> if the issue persists.

Agreed.  OdinMonkey isn't activated unless the JS code specifies "use asm" which GMail does not (it is easy to check; there is a warning printed to the WebConsole when "use asm" is present).  If you want to experiment with JITs that *are* used by a normal webapp, play with
  javascript.options.ion.{chrome,content}
  javascript.options.ion.{chrome,content}

Comment 23

[Luke Wagner [:luke]]

Oops, the second should be:
  javascript.options.baseline.{chrome,content}

Comment 24

[Tobias B. Besemer [:BesTo] (QA)]

(In reply to Florian Bender from comment #21)
> (In reply to Tobias B. Besemer from comment #20)
> > I tried: about:config > javascript.options.asmjs = false (restart maybe)
> > 
> > I can't say if FF now need less CPU, but my FF seems to be twice as fast as
> > before !!!
> > Even if there is no gmail open! Also the session restore of the browser is
> > much faster !!!
> 
> OdinMonkey should not affect the performance of Firefox, please do some test
> runs on a clean profile and file a new bug (worst case it gets duplicated)
> if the issue persists.

OK, I will play a little bit with the configuration but I tested it on an FF25 & FF26b ...

Isn't possible that the sessionstore.js or the Hangouts frame runs it ??? Or the G+ part of Google ???

Comment 25

[Luke Wagner [:luke]]

(In reply to Tobias B. Besemer from comment #24)
> Isn't possible that the sessionstore.js or the Hangouts frame runs it ??? Or
> the G+ part of Google ???

They don't.

Comment 26

[Tobias B. Besemer [:BesTo] (QA)]

Attachment: Browser-Konsole_2013-11-20_12-34-46.png

OK, this is a screenshot from my browser console when I open the GMail Inbox on FF25 without plugins and with NoScript.
I think I set the config back before.
Sorry, I use the German version of FF ... ;-)

Comment 27

[Tobias B. Besemer [:BesTo] (QA)]

(In reply to Luke Wagner [:luke] from comment #22)
> (In reply to Florian Bender from comment #21)
> > OdinMonkey should not affect the performance of Firefox, please do some test
> > runs on a clean profile and file a new bug (worst case it gets duplicated)
> > if the issue persists.
> 
> Agreed.  OdinMonkey isn't activated unless the JS code specifies "use asm"
> which GMail does not (it is easy to check; there is a warning printed to the
> WebConsole when "use asm" is present).  If you want to experiment with JITs
> that *are* used by a normal webapp, play with
>   javascript.options.ion.{chrome,content}
>   javascript.options.ion.{chrome,content}

> Oops, the second should be:
>   javascript.options.baseline.{chrome,content}

Can you explain me this little bit more or point me to a documentation to this ???

Is there a example page around that trigger OdinMonkey ???
Is OdinMonkey than only active for a single script or runs it then on more ???

Is there a Tech Evangelism (meta) bug for GMail (or Google) ???

Comment 28

[Luke Wagner [:luke]]

(In reply to Tobias B. Besemer from comment #27)
> Can you explain me this little bit more or point me to a documentation to
> this ???

There isn't documentation on these prefs; they are just internal controls used for triaging regressions and experimenting.  After you flip one of them off ('content' for web page content, 'chrome' for browser-internal JS), it turns off the associated jit: 'ion' is our high-end jit, 'baseline' is the low-end jit.  'javascript.options.asm.js' turns on/off OdinMonkey which only compiles asm.js.

> Is there a example page around that trigger OdinMonkey ???

unrealengine.com/html5

> Is OdinMonkey than only active for a single script or runs it then on more
> ???

It runs, at parse time, for all scripts containing "use asm" (which does not include GMail).

Comment 29

[Tobias B. Besemer [:BesTo] (QA)]

Attachment: 2013-11-22 19_42_56-about_memory.png

ATM my complete PC was hanging with I/O on the HD.
I opened 'about:memory' and made an 'Measure'.
The the talkgadget script (Hangouts) was hanging and gave an error message.
I think GMail needs (see screenshot) to much memory per tab.
Or is this normal ???
How can I help with more infos/tests ???

Comment 30

[Tobias B. Besemer [:BesTo] (QA)]

Attachment: 2013-11-22 20_10_01-Browser-Konsole.png

Comment 31

[Wayne Mery (:wsmwk)]

Did you test with options set to not use sessionrestore?  i.e. when firefox starts = home page or blank page

Comment 32

[Paul Silaghi, QA [:pauly]]

Do you still reproduce this on the latest nightly ?

Comment 33

[Simon Broenner]

I don't currently have time to test the nightly, but FF27.0.1 and FF28 seem to have gotten better. I'm not sure that we're back to pre-FF22 levels of power consumption, but I'm not seeing a huge drop in projected battery life any more when I leave GMail open.

Comment 34

[Mark Banner (:standard8)]

Comment on attachment 8336614 [details]
Browser-Konsole_2013-11-20_12-34-46.png

Dropping feedback request on long-closed bug with no feedback owner.