Closed Bug 1019877 Opened 6 years ago Closed 6 years ago

[B2G][Flame][Browser] Youtube videos are freezing and becoming unresponsive when tapping on the screen in fullscreen mode

Categories

(Core :: Graphics: Layers, defect)

30 Branch
ARM
Gonk (Firefox OS)
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla32
blocking-b2g 1.4+
Tracking Status
firefox30 --- wontfix
firefox31 --- wontfix
firefox32 --- fixed
b2g-v1.3 --- unaffected
b2g-v1.4 --- fixed
b2g-v2.0 --- fixed

People

(Reporter: jschmitt, Assigned: sotaro)

References

()

Details

(Keywords: regression)

Attachments

(3 files)

Attached file log.txt
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.
Keywords: qawanted
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
QA Contact: bzumwalt
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
blocking-b2g: --- → 1.4?
Component: Gaia::Browser → Video/Audio
Product: Firefox OS → Core
Version: unspecified → 30 Branch
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?
Blocks: 1006957
Component: Video/Audio → Graphics: Layers
Flags: needinfo?(sotaro.ikeda.g)
Ok, I am going to investigate the bug.
Assignee: nobody → sotaro.ikeda.g
Flags: needinfo?(sotaro.ikeda.g)
I confirmed the problem on v1.4 flame.
blocking-b2g: 1.4? → 1.4+
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.
Attachment #8434370 - Flags: review?(nical.bugzilla)
Status: NEW → ASSIGNED
Attachment #8434370 - Flags: review?(nical.bugzilla) → review+
https://hg.mozilla.org/mozilla-central/rev/6febca7ac438
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla32
You need to log in before you can comment on or make changes to this bug.