Precondition: 1. Enable 3G data or WiFi connection. STR: 1. Launch "facebook" application and login and check the power consumption. 2. Logout of facebook and check the power consumption. Actual: High current usage is noticed: 3G: Average Current 14.29 mA / Sleep Current 1.53mA WiFi: Average Current 92.85mA / Sleep Current 1.61mA Expected: The current consumption should be at average values.

Maybe this is a wifi bug? Not sure.

mlee, are you aware of power requirements here? It's unclear if the WiFi avg current is alarming.

Alex, there're no power perf requirements for 1.1 (leo). 1.2 will be our first opportunity to define, track and make fixes against those. Sandip, cc'd may have more info to share on product/partner goals.

Correct, We do not have app specific numbers. However I am not clear what the ask is here. Is the problem here that facebook app draws more current than other apps? (on 3G or wifi)? Note that Wifi and 3g current draws themselves are different irrespective of apps. Leo: Can you elaborate?

(In reply to Sandip Kamat from comment #4) > However I am not clear what the ask is here. Is the problem here that facebook > app draws more current than other apps? (on 3G or wifi)? We are observing a high consumption of current while using facebook application over wifi.

Leo will provide more analytic data to see if this is an app or wifi problem.

Needinfo'ing Leo to help with comment# 6.

Wrote too fast..also wanted to make sure comment# 3 is read and this may be blocking only if its a regression with STR

I am sharing more analysis values captured for different application. 3G values Facebook: Average current 159.8mA/Sleep current 48.5mA Twitter: Average current 109.3mA/Sleep current 22.6mA Browser: Average current 106.4mA/Sleep current 6.5mA Wifi Values Facebook: Average current 113.8mA/Sleep current 11.7mA Twitter: Average current 88.7mA/Sleep current 12.2mA Browser: Average current 119.47mA/Sleep current 9.2mA The average values calculated for a period of 3 minutes. Hope these data will be helpful.

Triage - per comment 9 the problem seems to be with facebook application and not the device/build itself. Leo considers this non-blocking for the release as the application is developed by facebook and out of Mozilla control. However, please follow up with facebook on this investigation. Hi Karen, can you reach out to facebook on this? Thanks.

Is there any update? leo have QE issue about this. Please let me know the current status.

I am hesitant to tell a partner that his apps needs to much power on our device. Especially without much detail into the "why" and when the app has a lot of functionality and connectivity like FB. Mike, who would be the right person to look into this and provide some starting point for further investigation?

Harald, Our team (FxOS Performance) is building hardware and software harnesses for measuring power usage on FxOS. Jon has built a few prototypes but not enough to send you one for testing Facebook's power draw yourself. Dave Huseby is working on getting the software automation pieces in place. Jon or Dave, How soon can we use the power harness you're creating to measure power usage for apps like Facebook? Is it possible to use what we have to give Harald some starting point for his investigation?

Dave has the harness, so he's going to have to run with this. Once I get the printer, I can easily create another one for myself.

how is this issue going?

We're getting close to being able to take great power data. I'm adding the blocker that this is waiting on.

We will get back to FB when we have better data. Until then assigning to Jason to find a better component.

I'm going to leave this in the general component for now. I'll work with the perf team when the power consumption tools are available to analyze this.

via DANIEL JESUS COLOMA BAIGES We are having some issues during the IOT Test of the 1.3 Devices to be launched. The scenario is open FB app (https://marketplace.firefox.com/app/facebook-1) as well as some other apps (e.g. Line) and switching the screen off. The behaviour we have seen is that the CPU is always awake and all the apps are active and hence the battery drains. The app that seems to keep CPU awake is the FB one by keeping an open socket that receive information every 40 secs (and responding through that socket too). When FB App starts: $ tail -f netstats.txt tcp 0 0 0.0.0.0:666 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:2828 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN tcp 0 0 10.2.205.137:60636 195.57.152.67:443 ESTABLISHED tcp 0 0 10.2.205.137:60635 195.57.152.67:443 ESTABLISHED tcp 0 0 10.2.205.137:37080 69.171.235.16:443 ESTABLISHED tcp 0 0 10.2.205.137:60640 195.57.152.67:443 ESTABLISHED tcp 0 0 10.2.205.137:37397 195.57.152.171:443 ESTABLISHED tcp 0 0 10.2.205.137:53711 31.13.80.81:443 ESTABLISHED tcp 0 0 10.2.205.137:60637 195.57.152.67:443 ESTABLISHED After a while (5 minutes) Proto Recv-Q Send-Q Local Address Foreign Address State tcp 0 0 0.0.0.0:666 0.0.0.0:* LISTEN tcp 0 0 0.0.0.0:2828 0.0.0.0:* LISTEN tcp 0 0 127.0.0.1:5037 0.0.0.0:* LISTEN tcp 0 0 10.2.205.137:37080 69.171.235.16:443 ESTABLISHED tcp 0 0 10.2.205.137:53711 31.13.80.81:443 ESTABLISHED So it seems FB apps keeps two sockets open to channelproxy-shv-13-prn1.facebook.com and edge-z-1-shv-01-cdg1.facebook.com. This is reducing battery life a lot and there is no benefit for the end-user as FB app is not popping up any notification (even when the device screen is off), so any information received in the background will not be shown until the user move FB app to the foreground again.

Colby, do you have ideas on how to fix this battery drain? I would think closing and re-opening the websocket when the the visibilitychange is fired. Another option is to just idle a bit more and reduce the amount of messages during the hidden state.

Hmm yeah that's no good. I think killing the connection on visibilitychange makes sense. I'll check with the folks who maintain the socket stuff and see what they think. Thanks for the heads up Harald.

The problem is not as much the connections being kept open (which by itself doesn't consume any CPU/battery) but that the server is sending data through that connections every 40 seconds (and this was on my own account, which isn't precisely what I would call very active). So every 40 seconds the CPU awakes, process whatever Facebook's server is sending (and incidentally every other process that was waiting for CPU also gets CPU time) and then tries to go back to sleep. What's worse, I don't think we even have time to put the radio into power saving mode (since it's being activated every 40 seconds). The attached file is a summary of a tcpdump running on the phone (with only FB app running) and the filter: ip.src == 69.171.235.16 or ip.dst==69.171.235.16 The time shown are relative times to the last filtered package (in other words, they're interval between consecutive packages on the attached log).

Colby, I also head on this issue in my project, FB drains a 60mA average current which is horrible for battery life. Waiting update from your side...

I did some testing of this today, and was unable to reproduce the results. The Facebook app was taking on average about 15mA more than just the homescreen by itself (both with the screen visible), and I didn't see any cycling of power usage on clearly defined boundaries (like 40-45 seconds). Note that I was running a dev build of 2.0 on a Hamachi for this test.

The team that owns server polling is working on a way to disable polling on visibilitychange. I'll keep you all posted once we have a fix.

(In reply to Colby Rabideau from comment #26) > The team that owns server polling is working on a way to disable polling on > visibilitychange. I'll keep you all posted once we have a fix. Thanks for the update, do you an ETA for the fix? It is important for us in order to schedule next battery test round.

Hi Colby - Also is it possible to provide an engineering release for us to verify first? We want to make sure that the power consumption of the device can indeed improved once the FB modify the polling mechanism. It would be best if we can have a test build of FB before end of Wednesday(May 7). Appreciate your help

vchen: FB is hosted so there are no "builds" per se. But if you send Colby your FB email he might be able to get you on the beta pool (if I remember correctly from the meeting, no promises). I also wouldn't put much priority on that, as looking at the feedback we collected there is a high chance that killing websockets will fix the battery issue. We don't have any attack vector so far. Is there any other debugging FB or Mozillas Partner Engineering could do to verify a fix. I imagine running the profiler using the App Manager and seeing how many cycles still happens when the phone is put so sleep?

(In reply to Harald Kirschner :digitarald from comment #29) > vchen: FB is hosted so there are no "builds" per se. But if you send Colby > your FB email he might be able to get you on the beta pool (if I remember > correctly from the meeting, no promises). I also wouldn't put much priority > on that, as looking at the feedback we collected there is a high chance that > killing websockets will fix the battery issue. We don't have any attack > vector so far. > > Is there any other debugging FB or Mozillas Partner Engineering could do to > verify a fix. I imagine running the profiler using the App Manager and > seeing how many cycles still happens when the phone is put so sleep? Hi Harald - i see...thanks for the feedback. I think your verification approach is solid, if we can have a comparison between a) with current FB, how many cycles still happens when the phone is put to sleep for 20 minutes. and b) with modified FB, how many cycles still happens when the phone is put to sleep for 20 minutes. If our partner can have this data, they can do the math and estimate what the power consumption gain will be from the FB modification. How do you think?

Hey guys, I've got a quick update from our end: The team working on this won't able to get the fix in for next week's release. They're expecting to have to code ready sometime next week, to be released the following Tuesday (5/20). We're proceeding cautiously here because the change will affect a core piece the msite infrastructure. I'll keep you posted as updates are available and look into using the App Manager profiler once we have a fix to test.

Hi Colby, Can you confirm if this has been already released? Thanks a lot! David (In reply to Colby Rabideau from comment #31) > Hey guys, I've got a quick update from our end: > > The team working on this won't able to get the fix in for next week's > release. They're expecting to have to code ready sometime next week, to be > released the following Tuesday (5/20). > > We're proceeding cautiously here because the change will affect a core piece > the msite infrastructure. > > I'll keep you posted as updates are available and look into using the App > Manager profiler once we have a fix to test.

Hey David, I just checked with the team, and unfortunately they weren't able to get the fix into this week's release. Hopefully, next week. I'll circle back with them on Thursday/Friday, and let you guys know how it's coming.

Hi Colby, Thanks for the update. Please, take into account that this is a blocking issue for launching in Spain. Let me know if we could help here... Thanks! David

Hi Colby, Do you have any update on this? Do you have an ETA for the new release? Thanks a lot! David

Hey David, the patch to pause server polling on visibility change went out this afternoon!

Thanks a lot Colby! We've been reported that battery measurements now are better and acceptable :) Again, thanks for all your help! David

Awesome! Glad to help!

> We've been reported that battery measurements now are better and acceptable :) Can we close this bug, then? Thanks.

Hi, Thanks for checking this. Closing the bug. Cheers, David