Firefox os v1.1 Mozilla build ID:20130817041203 Created an attachment (id=498064) JRDLOG DEFECT DESCRIPTION: Can not pause video when Alarm rings REPRODUCING PROCEDURES: 1、launch clock APP and set a alarm time 2、launch video player and play a video 3、the video can not pause when Alarm rings->KO1 4、it caused a minor flickering on the screen when Alarm rings->KO2 4、the video player force stop when snooze or close the alarm->KO3 EXPECTED BEHAVIOUR: the video should paused when Alarm rings->OK1 the screen should't flicker when Alarm rings->OK2 the video player keeps playing when snooze or close the alarm->OK3 ASSOCIATE SPECIFICATION: TEST PLAN REFERENCE: TOOLS AND PLATFORMS USED: USER IMPACT: moderate REPRODUCING RATE: 3/3 For FT PR, Please list reference mobile's behavior:

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Clone from brother

Please reassign as it is a clock issue.

I am going to add qawanted to confirm if its a regression from 1.0.1 which is the only case that we would block on this one.

Tested Unagi and Buri devices on 1.0.1. The issue does not repro. Instead, the video is stopped and the user is returned to the video list after canceling/snoozing the alarm. Environmental Variables Build ID: 20130715070214 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0 Gaia: 054cdc27404e2daca91d3065d9783681032b2151 Platform Version: 18.0

(In reply to Lucas A. from comment #29) > Tested Unagi and Buri devices on 1.0.1. The issue does not repro. Instead, > the video is stopped and the user is returned to the video list after > canceling/snoozing the alarm. > > Environmental Variables > Build ID: 20130715070214 > Gecko: http://hg.mozilla.org/releases/mozilla-b2g18_v1_0_1/rev/9c62297d11b0 > Gaia: 054cdc27404e2daca91d3065d9783681032b2151 > Platform Version: 18.0 Did you confirm you could reproduce this on 1.1?

Yes, I was able to reproduce on 1.1.

Any update?

Eric, can you take a look at this one?

Made leo+ since it is a regression issue.

Eric, can you comment to provide the status on this bug?

Hi Dylan, I can replicate this on my device. I'm looking into it now.

Any updates?

Eric,any findings?

Dylan, Haven't seen Eric's comments since a week. Hope this is being worked on.

Eric is working actively on this bug. From reading it over, however, it seems to me more likely to be a Video app bug or a System app bug than a Clock bug. Or maybe it is a combination of all three. I'm curious to know what happens when there is an incoming call with a video playing. If things work there, but not for an alarm, then maybe this is a system app issue. Setting needinfo to get input from John and Alive. Eric, John and Alive ought to be able to figure out what is going on here.

I try to reproduce the issue on build "mozilla-b2g18-hamachi-eng/2013/09/2013-09-24-04-12-00". But I'm not able to flash the image from pvt. It will get the error message as following: adbd is already running as root remount succeeded ls: /builds/slave/b2g_m-cen_hamachi_ntly-0000000/build/objdir-gecko/dist/b2g: No such file or directory cannot stat '/builds/slave/b2g_m-cen_hamachi_ntly-0000000/build/objdir-gecko/dist/b2g': No such file or directory Is QA team able to flash the latest build with Firefox os v1.1? Basically, it looks like an audio competing issue. I think Clock app don't have the ability to control Video app. As David's comment, we have to check the Audio channel competition normally or not.

After discussion with Ian and alive, I also think it is related to audio channel competition.

This bug is already under audio channel component now.

Hi all, I can't reproduce it on the newest v1-train today and I listed what version I tested it. Gaia: V1-train from https://git.mozilla.org/releases commit 2cae0622ee942906daaca90293441afdbd2cb7de Gecko: b2g18 from HG changeset: 119924:18175c7fdaa6 There are two things to let video app stop playing. 1. AudioChannel will cause video element to be paused during Alarm fired. 2. Video app itself will stop to play when it detect it is under background. Hi Ian, If you can reproduce it, I will check this with you. Thanks.

Reassigning to Marco since this has now moved to AudioChannel.

Able to reproduce the following issue on Buri 1.1 MOZ RIL The video is continuing to play with sound for another 2 seconds, after the alarm fires up The issue doesn't reproduce with Incoming call, the video is paused right away without delay when the Incoming call screen appears When receiving SMS the audio is muting for about 3 seconds but the video is continuing to play Build ID: 20130925041202 Gecko: http://hg.mozilla.org/releases/mozilla-b2g18/rev/18175c7fdaa6 Gaia: 6d9eec501a209bea945c6f841400ec0a75fac11d Platform Version: 18.1

I'm guessing the change back to Eric was a mistake -- I don't think he is the right assignee here.

Hi Sync-1, May I double confirm that comment 46 is what you met and fired here? Thanks.

(In reply to sarsenyev from comment #46) Hi all, Let me recap one audio competing policy first. The foreground audio can be playable always. So both of audio competing policy and video app depend on visibility change for pausing the media element. > Able to reproduce the following issue on Buri 1.1 MOZ RIL > The video is continuing to play with sound for another 2 seconds, after the > alarm fires up Please refer to the log as below. video app needs 2.61 seconds for a visibility change event after alarm is fired. This is the root cause of this situation. 09-26 14:49:01.220 I/AudioManager( 1742): NotifyOwnerDocumentActivityChanged hidden 0 ... 09-26 14:49:03.830 I/AudioManager( 1569): NotifyOwnerDocumentActivityChanged hidden 1 > When receiving SMS the audio is muting for about 3 seconds but the video is > continuing to play > In this case, I found that video app didn't receive any visibility change event and this is the root cause. ----------------- Alive may need to help this case about timing of visibility change event.

(In reply to Marco Chen [:mchen] (PTO, 09/16, 09/18~09/22) from comment #48) > Hi Sync-1, > > May I double confirm that comment 46 is what you met and fired here? > Thanks. Yeah, KO1 is same with comment 46 , KO2 can't reproduce now and KO3 is not mentioned by comment 46.

The issue exactly is talking about: there is a 3sec delay before we set visibility of app under attentionscreen. I have some ways to fix this but I think this should not be considered to be a blocker for 1.1 Because the video in the end stops after 3 sec delay. It's not really "Cannot pause" anyway.

FYI https://bugzilla.mozilla.org/show_bug.cgi?id=875254

Hi, I'd like to help but I wonder it's really too late to make this blocks leo release, also this isn't a regression IMO, it was a 'wrong-but-acceptable' design from long time ago. I'd like to renom this for koi+.

Set category to Gaia::System because it is related to timing of visibility change event.

Given how close we are in 12 and we have already shipped with this regression once, I am blocking it for 1.3, so this gets fixed.

Alive, do you want to take it?

Not v1.3 blocking since attention-window is not in scope of 1.3.

Considering this is recoverable and user will most likely be watching video and able to respond to the alarm, pushing this out since a fix is incoming after window manager updates. Adding to backlog.

(In reply to Bruce Huang [:bhuang] <bhuang@mozilla.com> from comment #60) > Considering this is recoverable and user will most likely be watching video > and able to respond to the alarm, pushing this out since a fix is incoming > after window manager updates. > Adding to backlog. v1.5 maybe too later, v1.4 ?

It'll cause incoming call performance issue, v1.3T.

Adding qawanted to confirm if the experience is regressed further on tarako ? If the behavior is same as on 1.3, we would not block on 1.3T.

(In reply to bhavana bajaj [:bajaj] from comment #64) > Adding qawanted to confirm if the experience is regressed further on tarako > ? If the behavior is same as on 1.3, we would not block on 1.3T. Doubt it. This bug has been around since 1.1.

Tested w/ buri v1.3 and tarako v1.3t. The video stopped on buri but didn't stop on tarako while incoming call. Video stopped on both of the devices while clock alarm rang.

With comment 66, Alive, are you still the right assignee of this bug? If not, feel free to re-assign.

Comment 66 seems a edge bug for tarako only, so I propose to fire another bug for it. Al, I think you misunderstand this one, it's not talking about 'video does not stop playing', but 'video continues playing for 3 seconds after alarm or call coming. (Note, it finally stops.)

I modified the bug summary for not causing confusion.

Given the recent QA testing and bug comments this was discussed in triage and is not a blocker for release of 1.3T

I think it will cause tarako v1.3t performance issue. Do we miss some patch has been merge into v1.3 but not on v1.3t?

(In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #51) > The issue exactly is talking about: > there is a 3sec delay before we set visibility of app under attentionscreen. > I have some ways to fix this but I think this should not be considered to be > a blocker for 1.1 > Because the video in the end stops after 3 sec delay. It's not really > "Cannot pause" anyway. I think 3sec delay will cause tarako performance issue. Peipei, can you confirm it?

No we don't miss anything from 1.3 - there is a daily merge from 1.3 to 1.3t

(In reply to James Zhang from comment #72) > (In reply to Alive Kuo [:alive][NEEDINFO!][:艾莉芙] from comment #51) > > The issue exactly is talking about: > > there is a 3sec delay before we set visibility of app under attentionscreen. > > I have some ways to fix this but I think this should not be considered to be > > a blocker for 1.1 > > Because the video in the end stops after 3 sec delay. It's not really > > "Cannot pause" anyway. > > I think 3sec delay will cause tarako performance issue. Peipei, can you > confirm it? I saw the 3sec delay on tarako build 20140318033320. Besides this, I didn't see other performance issues.

base on comment 68 and comment 74, this does not seem like the highest priority for tarako at this moment, minus

In today's build, I spent 30 seconds with only sound and no video (black screen other than the status bar). The alarm sounded 1 minute later than it should have sounded Gaia acd18bbd94ebfa534e252a24a75a0617e4b5d5ae Gecko https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/91a1b54da4a6 BuildID 20140404004001 Version 28.1 ro.build.version.incremental=eng.cltbld.20140404.044841 ro.build.date=Fri Apr 4 04:48:48 EDT 2014 Tarako

The Tarako behaves pretty much as expected in this scenario. When the alarm triggers, the video pauses, and the alarm alert appears without any flickering. After dismissing the alert, the video remains paused, but resumes at the right place when the play button is pressed. Current performance is much improved.

Alive, is this bug a dup to what's already been fixed?

Bug 927862 should fix |3、the video can not pause when Alarm rings->KO1| already, I am not sure about the remaining issues.

Let's dup the bug then.