STR 1. Play any video on youtube. Then, it shows large spinner with several circles. 1) Then, push home button -> power button. 2) Then, push just power button. In this case, device cannot go to sleep mode because it consumes more than 30mA steadily. This problem appeared after applying patch from bug 887454. On more STR, 1. Play any video on youtube. 2. while playing, try to seek and push power button. This STR causes same symptom.

This problem is different with bug 881584. In the case of 881584, it woke up periodically. But in this case, it consumes static value of power.

I think randy's work on bug 894249 could resolve this?

The video tag should be stopped when device press the power key. Hi JW, I test to uplift the audio channel from normal to content can solve this bug, Could you also consider this issue when fix the bug 894249?

Here is the possible solution. 1. Add one argument in RegisterAudioChannelAgent() for whether it is an audio or video. (only useful when it is a normal channel) 2. We can extend the AudioChannelInternalType in AudioChannelService to have AUDIO_CHANNEL_INT_NORMAL_AUDIO/VIDEO AUDIO_CHANNEL_INT_NORMAL_HIDDEN_AUDIO/VIDEO 3. When firing visible-audio-channel-changed from AudioChannelService, set the name to normal-video or normal according to internal type. 4. Then window_manager.js can limit the hack on visibility change to normal only but normal-video.

5. We need to do corresponding modification on sound_manager.js too.

(In reply to Marco Chen [:mchen] from comment #4) > > 3. When firing visible-audio-channel-changed from AudioChannelService, set > the name to normal-video or normal according to internal type. > I think it's better to keep current event(audio-channel-changed) but provide more detail in the event detail about video or audio. (In reply to Marco Chen [:mchen] from comment #5) > 5. We need to do corresponding modification on sound_manager.js too. I'm going to file a gaia bug for gaia change, leo could you help to leo+? thanks. This one should dupe to bug 894249 IMO.

I applied patch in Bug 894249 but I cannot get progress for this symptom. The problem still occur.

(In reply to leo.bugzilla.gecko from comment #7) > I applied patch in Bug 894249 but I cannot get progress for this symptom. > The problem still occur. Can you try https://bugzilla.mozilla.org/attachment.cgi?id=791197? The patch is not complete without modification to window_manager.js/sound_manager.js. It is used to bypass the audio channel hack in window manager for testing purpose.

Hi Leo, Could you post the power diagram for us to reference?

Please refer attached data. There are three periods. 1. Push power button while playing : 0.3 Min ~ 1.4 Min 2. STR in comment #0 : 1.7 Min ~ 2.5 Min 3. kill all apps and push power button : 2.7 Min ~ What I told here is about period 2.

In the period 2, it keep consuming more than 30mA. And if you leave it, the value never decreases.

Hmm.....According to my data... Period 1 has anther problem. It should have same value as period 3 but It doesn't. If needed, I will create another issue for this.

How long does the high current persist in STR1? Does it last more than 5 minutes? In our test, it will eventually go down after 1 or 2 minutes. It looks like HTMLVideoElement is busy in processing tasks in the background without holding CPU wake lock and therefore it takes much longer for CPU running in low frequency.

(In reply to jwwang from comment #15) > How long does the high current persist in STR1? > Does it last more than 5 minutes? > > In our test, it will eventually go down after 1 or 2 minutes. It looks like > HTMLVideoElement is busy in processing tasks in the background without > holding CPU wake lock and therefore it takes much longer for CPU running in > low frequency. Please check Attachment #792498 [details]. It doesn't drop more than 20 minutes. Even if it goes down after 1 or minutes sometimes, this is regression because of bug 887454 and should be fixed.

QA, Please check if this bug is a regression.

If you check bug 881584, CPU goes to idle after similar STR.

I was able to find out when the problem started occurring.The youtube video’s started playing on the browser instead of video player right after 07/09. Now after pushing the power button the user is able to listen to the video and the video kept playing in the background, whereas before 07/10 the user did not hear any video playing in the background after pressing the power button Looks like the regression happened somewhere between 07/09 and 07/10 Issue does not reproduce on Build ID: 20130709070206 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/f917f3fb17ab Gaia: e251ee6bdab13d8620afa8f9c2d5f14e5e6a4f99 Platform Version: 18.1 RIL Version: 01.01.00.019.157 Issue started occurring on Build ID: 20130710230201 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/b64372810dd7 Gaia: 680c72ccbd2d5045e590a6ba08de2aac6af71953 Platform Version: 18.1 RIL Version: 01.01.00.019.158

It's because of https://bugzilla.mozilla.org/show_bug.cgi?id=887454 which is told to be an "intentional regression". (In reply to dkumar from comment #20) > Looks like the regression happened somewhere between 07/09 and 07/10

This has not gone through Mozilla triage yet, and is very late in the cycle. We're going to reconsider as more information comes in.

This is a regression, so something needs to be done one way or the other so back to blocking+.

Alive, what's the bug # for the Gaia piece you mention in comment #6?

(In reply to Alive Kuo [:alive] from comment #6) > This one should dupe to bug 894249 IMO. Let's keep this open, and once bug 894249 and the Gaia piece land, partner can retest and close this upon verification that the fixes resolve the problem.

(In reply to Dietrich Ayala (:dietrich) from comment #24) > Alive, what's the bug # for the Gaia piece you mention in comment #6? https://bugzilla.mozilla.org/show_bug.cgi?id=908562 filed.

Blocks a blocker.

Power consumption is very sensitive issue. This issue is urgent with high-priority...

Hello Alive, Are you working on this bug? jwwang, The bug is assigned to you. Are yo still working on this bug?

Once Bug 894249 is landed, this bug should be also solved as indicated in comment 25.

John, Similar to 894249.

Ryan Please comment similar to: 894249

Shouldn't QA confirm that this is fixed?

QA Wanted - Can someone retest this to see if it's fixed?

Smaller STRs: 1) have a full page of icons, take one icon from the dock/hotseat and while the icon is still in the dock paginate the last icon on the homescreen, if the last icon in the dock doesn't move back to the page, then you reached one part of the condition 2) move the icon back in the dock and then to the top of the homescreen, don't let go 3) have another finger ready to press a different icon, let go of the original moving icon and immediately press the second icon [ You can see this at 0:23 of the original video ]

oops. please ignore the last comment. I had the wrong bug.

Currently, I am seeing the same behavior on v1.1 as described in comment 20. When playing youtube video on the device and pushing the power button, video does not stop and user is still able to hear the sound from the video played on the device. But seems like it is by design (see comment 9 of bug 906612 and comment 11 of bug 908562) We don't have tools to check the power consumption, though. Leo Build ID: 20130927041201 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/9e45dd3f5428 Gaia: f3b30b19d80240c9cc2aa2002398c902fd1d6375 Platform Version: 18.1 RIL Version: 01.01.00.019.236

(In reply to Mila Davydova from comment #37) > Currently, I am seeing the same behavior on v1.1 as described in comment 20. > When playing youtube video on the device and pushing the power button, video > does not stop and user is still able to hear the sound from the video played > on the device. But seems like it is by design (see comment 9 of bug 906612 > and comment 11 of bug 908562) > We don't have tools to check the power consumption, though. > > Leo Build ID: 20130927041201 > Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/9e45dd3f5428 > Gaia: f3b30b19d80240c9cc2aa2002398c902fd1d6375 > Platform Version: 18.1 > RIL Version: 01.01.00.019.236 Right, that's by design. We need someone with power consumption tools to verify this. Jon - Could you look into this?

Joh just tested this. Results are here: https://www.dropbox.com/s/m61cw7uav241uze/Screenshot%20from%202013-09-27%2016%3A25%3A33.png Baseline = 45 - 50 mA Peak = 150 mA The reporter mentions this problem is present when power is greater than 30 mA consistently, which means that this bug isn't fixed.

Note that after 10 minutes, the video stops playing, and power consumption drops to zero: https://www.dropbox.com/s/7bwwgt4ape8fsmt/Screenshot%20from%202013-09-27%2016%3A36%3A33.png

This shot shows power consumption after about 2 minutes, with a baseline of about 45-50 mA.

This shot shows after 10 minutes, when the video stopped playing, and power consumption dropped to zero.

After turning the device back on, the Youtube screen showed a big "X", with the following message: "Video playback aborted due to a network error", which says to me that wifi shut down after 10 minutes, thus the video stoppage and power use going to zero. (I added the dropbox-linked images as attachments, in case I ever clean up my dropbox folder and they disappear)

Sorry, one more thing - this test was run on a Hamachi, with last night's (Sept 27) v1-train nightly image flashed. The phone does not have a sim card in it, and wifi was (obviously) enabled.

So is it still a bug for power consumption goes to zero after wifi shuts down? Or it is a bug for wifi should shut down earlier?

No power usage goals set for 1.3. Currently being defined. Target release to be identified and updated here.

Hi Jon, According to your test result, is this bug fixed?

I have no idea at this point. I described what the system does. Comments in the bug seem to indicate that this behavior is "by design", which would imply no bug (C 37). Other comments say its a regression, thus a bug (C 23). Someone needs to determine (a) what the real problem here is, and (b) whether or not this is actually a problem. I'm not the right person for that.

Hi Leo, per comment #42, can you verify if this bug still exsits? Thanks.

This appears to not be a bug, since the video should continue playing after the screen is shut off (people often listen to music videos this way). There is a bug here that needs to be filed, regarding the wifi dropping the connection after ~10 minutes while video is playing.