Description: When a user is playing a video and receives another video via Bluetooth, selecting the notification will bring up a blank screen with a spinner while the first video's audio continues. Repro Steps: 1) Update a Flame device to BuildID: 20141023001201 2) Navigate to Settings, then Bluetooth. 3) Turn on Bluetooth then pair with another device. 4) Return to the homescreen and launch the Video app. 5) Select a video to play. 6) Receive a file request for a video from the other device. 7) Tap the request notification and accept the transfer. 8) Once the transfer completes, tap the notification while the video in step 5 continues to play. 9) Observe the appearance of the page. Actual: A new video window appears with a loading spinner. Video is not shown and the audio of the already-playing video continues to play. Tapping the screen will show the info bar for the received video. Expected: The already playing video stops and the received video begins playing, with no errors to audio or video. Environmental Variables: Device: Flame 2.1 BuildID: 20141023001201 Gaia: 1e48e3e40e0780c0cd07a3457e5fe2efeeb542d1 Gecko: 09fb60a37850 Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Platform Version: 34.0 Firmware Version: V188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Repro frequency: 100% See attached video clip and logcat logs

QA-Wanted for branch checks

The bug repros on Flame 2.2, 2.1, 2.0 and 2.0 base on both nightly (full flash) and engineering (shallow flash). Actual result: After tapping the "transfer complete" notification, the received video will attempt to load. However, the only thing the user will see and hear is a loading spinner and the video that is already playing. Flame 2.2 BuildID: 20141024070214 Gaia: 29ed78a26d62b58f663437a45f273d57b9781d79 Gecko: d6abb9bf43be Platform Version: 36.0a1 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Nightly BuildID: 20141024040202 Gaia: d893a9b971a0f3ee48e5a57dca516837d92cf52b Gecko: a5ee2769eb27 Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Platform Version: 36.0a1 Firmware Version: V188 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Flame 2.1 BuildID: 20141024064808 Gaia: 07cd1562b90960a343104a67b184cf9e01bee8a0 Gecko: 4feccadc6146 Platform Version: 34.0 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Nightly BuildID: 20141023001201 Gaia: 1e48e3e40e0780c0cd07a3457e5fe2efeeb542d1 Gecko: 09fb60a37850 Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Platform Version: 34.0 Firmware Version: V188 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0 Flame 2.0 BuildID: 20141024064809 Gaia: 1a89b5317dbc31da9c604d677a4a5a3e34122a17 Gecko: cfa7cdcb728b Platform Version: 32.0 Firmware Version: V180 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Nightly BuildID: 20141024000201 Gaia: 86d83f4b4111ca45ebc92ca779348cc966f43cff Gecko: f8432250efb7 Gonk: 05aa7b98d3f891b334031dc710d48d0d6b82ec1d Platform Version: 32.0 Firmware Version: V188 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0 Flame 2.0 Base BuildID: 20141016183911 Gaia: 8c5c956ee6909408e29f375cc7d843a03d92f3d8 Gecko: Platform Version: 32.0 Firmware Version: V188 User Agent: Mozilla/5.0 (Mobile; rv:32.0) Gecko/32.0 Firefox/32.0

NI to Bluetooth owner to make a blocking decision

[Blocking Requested - why for this release]: Obvious error, please refer the URL link http://youtu.be/dt38xcRNn20 .

changing component to video, please reassign if needed, thanks

Probably a missed case. Ni John Hu for any input on this. David, could you please investigate. Thanks Hema

It seems there is contention for the hw video codec in this case. The video app is using the video codec to play the video while the 'view' layer is trying to play the shared video. The video codec can't be shared so the 'view' waits for the video codec to be free, which it won't be because the video app has no reason to release it. If I'm correct, it may be possible to indicate to the video app that it needs to release the video codec. I'm not sure how to do that. I tried sending an event from the 'veiw' layer (view.js) to the video app but the video app is not receiving it.

Hi Hema, I got the same NI? about almost the same root cause at the same time. The analysis of Russ is correct. It's a competition of HW codec. Gecko will play the second video while the first player released the HW codec. The root cause of this issue is video app doesn't know it goes to background. It just because the view activity is an inline activity. And system app doesn't send visibility change event to video app in this case. BTW, this inline Activity is sent by BT app which never goes to foreground. So, the inline activity is put on top of video app. Because of it is on top of video app, video app doesn't need to go to background. Otherwise, the video app may be killed by LMK. This may be the reason why system app doesn't send visibility change at this case. But I am not really sure about this. ---------------------------------- (In reply to Russ Nicoletti [:russn] from comment #7) > If I'm correct, it may be possible to indicate to the video app that it > needs to release the video codec. I'm not sure how to do that. I tried > sending an event from the 'veiw' layer (view.js) to the video app but the > video app is not receiving it. Hi Russ, I am curious about how you send an event from view to video app. From my current knowledge, video app doesn't know there is another window loads view.html and vice versa. There are few ways to let them communicate to each other: 1. use SharedWorker to bridge message between them. 2. use LocalStorage to bridge message between them, but this is a really hack way to do so. 3. use datastore to bridge message between them. ---------------------------------- Hi Blake, Please also look at this issue. Bug 1085212 MAY be fixed when this issue is fixed. The root cause of these two issues are the same.

Hi John, Thanks for your information! It looks like if video file is shared with E-Mail, Message, and Bluetooth, user will hit the same problem.

(In reply to Russ Nicoletti [:russn] from comment #7) > > If I'm correct, it may be possible to indicate to the video app that it > needs to release the video codec. I'm not sure how to do that. I tried > sending an event from the 'veiw' layer (view.js) to the video app but the > video app is not receiving it. Russ: the system app always launches a new instance of the app to handle inline activities. So you'd have to use an inter-app communication channel to make this work. A settings db hack or the IAC api or something. Ideally, though we'd just get a visibility change event and not have to worry about this. I don't really think that this is a video app bug.

John's analysis is right on. The video app stops playing when it gets a visiblity change notification and goes to the background. For inline activities, the system app does not send the invoking app to the background and instead runs the activity with two foreground apps. This is becasuse for activities like pick, there is a return value and it is critical that the requesting app remains alive to receive the return value. If that app was sent to the background, then it could more easily be killed by OOM. We had a lot of nasty bugs because of that. (In this case, for a view activity, there is no return value, and the system app could relax on this point.) I'd say that the real bug here is that the system app thinks the video app is the foreground app in this situation. It is launching an activity on behalf of the bluetooth app, so it should send the video app to the background in this case. So I think we've got the wrong component here. This is a bluetooth bug or a window management bug. Also, the patch for 1079519 will hopefully mitigate this and at least display a (possibly unlocalized) message when this bug occurs. Alive: do you think this could be fixed in the window management code? Or is there something that the bluetooth app could do differently when invoking the activity to prevent this?

(In reply to Blake Wu [:bwu][:blakewu] from comment #9) > Hi John, > Thanks for your information! > It looks like if video file is shared with E-Mail, Message, and Bluetooth, > user will hit the same problem. Good catch! Strangely, video playback stops when I share with email, but not when I share with the messaging or bluetooth apps. Perhaps they register their share activities as inline rather than window disposition? In any case, we can fix this part easily in the video app by just pausing the current video before initiating a share activity.

I've filed bug 1091843 for the share activity part of this bug, and we can fix that in the video app. But I think that the rest of this bug is related to window management, so switching back to that component. As noted above, bug 1079519 may be able to mitigate this by displaying a "can't play video" message when there is already a video playing. That bug is also a 2.1 blocker, so it might be good enough for this bug, too.

(In reply to David Flanagan [:djf] from comment #11) > John's analysis is right on. > > The video app stops playing when it gets a visiblity change notification and > goes to the background. > > For inline activities, the system app does not send the invoking app to the > background and instead runs the activity with two foreground apps. This is > becasuse for activities like pick, there is a return value and it is > critical that the requesting app remains alive to receive the return value. > If that app was sent to the background, then it could more easily be killed > by OOM. We had a lot of nasty bugs because of that. (In this case, for a > view activity, there is no return value, and the system app could relax on > this point.) > > I'd say that the real bug here is that the system app thinks the video app > is the foreground app in this situation. It is launching an activity on > behalf of the bluetooth app, so it should send the video app to the > background in this case. > > So I think we've got the wrong component here. This is a bluetooth bug or a > window management bug. > > Also, the patch for 1079519 will hopefully mitigate this and at least > display a (possibly unlocalized) message when this bug occurs. > > Alive: do you think this could be fixed in the window management code? Or is > there something that the bluetooth app could do differently when invoking > the activity to prevent this? The root cause is https://bugzilla.mozilla.org/show_bug.cgi?id=892371 System app cannot send activity caller to background due to process priority issue; unfortunately in this case video app is treated as the activity caller because it is the top most app when you launches an activity. And yes we have trouble to identify the app is the caller or not, because sometimes gecko will fire the mozActivity for the app (anchor link case) so we cannot simply say the top most app is not the caller if the event src of the launch activity request is system app. For this issue I will suggest a workaround for video app: if the video activity is just opened, then send a message (in worst case: localstorage; in better case: shared worker) to video app to notify it: "hey someone invokes me so if you are alive, please release the video resource." Music app is using similar strategy to stop the playing audio of music app when music activity is launched and both of them are foreground. (And we will correctly fix that by https://bugzilla.mozilla.org/show_bug.cgi?id=961967) I am sorry to say this, but it's nearly impossible to fix it in system app side now. I am working with platform guys to make sure they have resource to fix bug 892371 but I don't have a schedule from them now. Does the proposal works for you?

Okay, based on Alive's comment, I'm taking this bug back and re-assigning to the Video app component. Alive: thanks for mentioning that Music has to do something similar. The workaround in that app seems simple, and it should be easy to do something similar here. I'm also going to close bug 1091843 and fix that issue as part of this one as well.

Russ, This patch uses a hack similar to the music app. It uses localStorage to allow view.html running in one process to send a message to index.html (the regular app) running in a separate process. If we're playing a video when we get that signal we go back to the list of thumbnails just as if the user clicked the back button. In my testing that fixes this bug and allows the view activity to play. I've also included code to pause the playing video when the user brings up the menu of share/delete/info options, so that the video doesn't keep playing if the user tries to share it.

Comment on attachment 8515328 [details] link to patch on github Just one nit, comment is in the PR.

Waiting for tests to run and the gaia tree to reopen and this can land.

Landed on master: https://github.com/mozilla-b2g/gaia/commit/7c9e7cabbde941b976e0e40a3a1d94e21aa9c5e9

Comment on attachment 8515328 [details] link to patch on github [Approval Request Comment] [Bug caused by] (feature/regressing bug #): not really a regression, just a corner case that hadn't been discovered before, or maybe a regression caused by system app window management changes some time ago. [User impact] if declined: viewing a video right after bluetooth download won't work if another video is being played. [Testing completed]: locally [Risk to taking this patch] (and alternatives if risky): Not risky. There is some interapp communication via localStorage, but that is not on the startup path for the video app, so it shouldn't affect performance. [String changes made]: none.

Bug 1085212 is closely related to this one and is 2.0+. The fix for 1085212 will basically need to include the fix for this bug as well, so I'll probably end up reverting this patch, marking this bug as a dupe of that one, and landing a single fix for both bugs in bug 1085212.

v2.1: https://github.com/mozilla-b2g/gaia/commit/153e8dad29e248d3cf8f9a0c6d436936a184c272

Verified the issue is fixed on master build 2.2 A video stops and the received video begins playing, with no errors to audio or video. Device: Flame 2.2 Master BuildID: 20141105040206 Gaia: 7c9e7cabbde941b976e0e40a3a1d94e21aa9c5e9 Gecko: 62990ec7ad78 Gonk: 48835395daa6a49b281db62c50805bd6ca24077e Version: 36.0a1 (2.2 Master) Firmware: V188-1 User Agent: Mozilla/5.0 (Mobile; rv:36.0) Gecko/36.0 Firefox/36.0 Adding "Verifyme" for 2.1 and 2.0

The patch I landed here only releases the hardware if the video is actually playing. The patch tests the playing variables when it should have tested the playerShown variable. So I think that if we start playing a video and then pause it and then receive another video by bluetooth, the newly received video will not play. That was my screw up. Given that this bug has already been landed and uplifted, however, I think it might be better to fix this remaining issue in the related bug 1085212 which is 2.0+. Alternatively we could revert this patch and re-land a proper fix.

This issue is verified fixed on Flame 2.1. Result: The newly received video plays properly. Device: Flame 2.1 (319mb, KK, Shallow Flash) BuildID: 20141111001201 Gaia: 7154f9aa0a69af56c8bd89be0c98d9791449527b Gecko: 452db1a0c9a0 Version: 34.0 (2.1) Firmware Version: v188-1 User Agent: Mozilla/5.0 (Mobile; rv:34.0) Gecko/34.0 Firefox/34.0