Description: Youtube videos are freezing when the user taps on the screen when in fullscreen mode, the audio continues playing. Repro Steps: 1) Update a Flame to 20140603000203 2) Launch the Browser app 3) Proceed to Youtube.com 4) Select a video to play 5) Play the video and go into fullscreen mode 6) Rotate to landscape 7) Tap on the screen multiple times Actual: The Youtube video freezes but sound continues to play. Expected: The video does not freeze. Environmental Variables: Device: Flame Build ID: 20140603000203 Gaia: d108159874cb594e7068a5c8384f05f0a8910bfd Gecko: 42d80aea48e3 Version: 30.0 (1.4) Firmware Version: v10G-2 User Agent: Mozilla/5.0 (Mozilla; rv:30.0) Gecko/30.0 Firefox/30.0 Notes: Repro frequency: 100% See attached: logcat, https://www.youtube.com/watch?v=QYyjU-7ohIc

Issue does NOT repro on 1.4 Buri. Qawanted to test on 1.3 Flame base.

Issue does not occur on trunk so this could be a regression within the 1.4 Branch Environmental Variables: Device: Flame Build ID: 20140603040210 Gaia: 61cd07a8b5fa017777db6d345e00afb4fb8789b7 Gecko: f28005b84ed0 Version: 32.0a1 (2.0) Firmware Version: v10G-2

Issue does NOT occur in 1.3 Flame base Result: The video does not freeze. BuildID: 20140520094859 Gaia: a73235d23685e9898f40647cebd83b3fcbfd0117 Version: 28.0 Firmware Version: v10G-2

Last Working Tinderbox: Device: Flame v1.4 BuildID: 20140529003002 Gaia: 7bc1c15c67661a0b8e35f18f15a9d03d1d2cfcd5 Gecko: 2181cac4d0fc Version: 30.0 Firmware Version: v10G-2 First Broken Tinderbox: Device: Flame v1.4 BuildID: 20140529075122 Gaia: fe612fd21389193a8e593aa718831602e5086a62 Gecko: 92b9901058d5 Version: 30.0 Firmware Version: v10G-2 Broken Gaia with Working Gecko - Does NOT occur Gaia: fe612fd21389193a8e593aa718831602e5086a62 Gecko: 2181cac4d0fc Working Gaia with Broken Gecko - DOES Occur Gaia: 7bc1c15c67661a0b8e35f18f15a9d03d1d2cfcd5 Gecko: 92b9901058d5 Appears to be Gecko issue Tinderbox Pushlog - http://hg.mozilla.org/releases/mozilla-b2g30_v1_4/pushloghtml?fromchange=2181cac4d0fc&tochange=92b9901058d5

Broken by bug 1006957. Sotaro - Can you investigate?

Ok, I am going to investigate the bug.

I confirmed the problem on v1.4 flame.

I confirmed that the problem is caused by deadlock at AsyncTransactionTrackersHolder. By bug 1006957, some main thread related events become to be delivered via ImageBridge. And RemoveTextureFromCompositableTracker hold reference counted pointer of CompositableClient. If the RemoveTextureFromCompositableTracker holds CompositableHold tracker's last reference, the CompositableClient's destructor is called on ImageBridge thread, even when CompositableClient belongs to main thread. And within CompositableClient's destruction, AsyncTransactionTrackersHolder's function called again. The function need to hold mutex, then fall into the deadlock.

Call stacks of deadlock related threads.

This deadlock has 2 problems. -[1] CompositableClient's destructor could be called on ImageBridge thread, even when the CompositableClient belongs to main thread. CompositableClient can not handle this situation, although TextureClient can handle this situation. -[2] During CompositableClient's destruction, AsyncTransactionTrackersHolder::ClearAllAsyncTransactionTrackers() is called. CompositableClient is derived from AsyncTransactionTrackersHolder.

From Comment 10, the deadlock could potentially happen also on master.

The problem is AsyncTransactionTracker holds reference-pointer of AsyncTransactionTrackersHolder(CompositableClient).

By locally removing the reference to CompositableClient, the problem is fixed on v1.4 flame.