Closed Bug 1127727 Opened 5 years ago Closed 5 years ago

[e10s] Detached tab with shared video is displayed with a large throbber after re-attachment

Categories

(Core :: WebRTC: Audio/Video, defect)

38 Branch
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla40
Tracking Status
e10s m6+ ---
firefox40 --- fixed

People

(Reporter: adalucinet, Assigned: handyman, NeedInfo)

References

(Blocks 2 open bugs)

Details

Attachments

(1 file, 1 obsolete file)

Reproducible on Nightly 38.0a1 (Build ID: 20150129030202) *only* with e10s enabled
Platforms: Mac OS X 10.9.5, Ubuntu 12.04 32 bit, Windows 8.1 64 bit and Windows 7 32 bit

Steps to reproduce:
1. Launch latest Nightly.
2. Open a New tab and navigate to https://people.mozilla.org/~fqueze2/webrtc/
3. Click on Video or Audio&Video button and select 'Share Selected Device'.
4. Drag tab with shared video in a New Window.
5. Re-attach tab from step 4.

Expected result: Shared video is displayed properly.
Actual result: A large throbber is displayed; video icon is still visible in the URL bar.

Notes:
1. Screenshot: http://i.imgur.com/oJ8RC5Y.png
2. At step 4, the video in the detached tab is not smooth.
3. Switching the tab with shared video fixes this issue - both detached and reattached tabs, but the URL bar remains empty. 
4. No errors in Browser console.
Maire, who would be the right person to figure this out?
Flags: needinfo?(mreavy)
Brad -- The lack of rendering makes me think this is a general e10s issue (not a webrtc or video rendering issue).  Can you find someone on the e10s team to look at this, or do you need me to find someone?  Thanks.
tracking-e10s: --- → ?
Flags: needinfo?(mreavy) → needinfo?(blassey.bugs)
Assignee: nobody → davidp99
Flags: needinfo?(blassey.bugs)
This patch swaps the MozLayersReady callback used by the tab-busy throbber when dragging tabs between windows.

Tests look good now: https://treeherder.mozilla.org/#/jobs?repo=try&revision=69cedf419600
Attachment #8591005 - Flags: review?(bugs)
Comment on attachment 8591005 [details] [diff] [review]
Swap MozLayerReady callbacks in SwapFrameLoaders

>+TabParent::SwapLayerTreeObservers(TabParent* aOther) {
{ goes to its own line

>+CompositorParent::SwapLayerTreeObservers(uint64_t aLayerId, uint64_t aOtherLayerId) {
ditto

>+  EnsureLayerTreeMapReady();
>+  MonitorAutoLock lock(*sIndirectLayerTreesLock);
>+  NS_ASSERTION(sIndirectLayerTrees.find(aLayerId) != sIndirectLayerTrees.end(),
>+    "SwapLayerTrees missing layer 1");
>+  NS_ASSERTION(sIndirectLayerTrees.find(aOtherLayerId) != sIndirectLayerTrees.end(),
>+    "SwapLayerTrees missing layer 2");
>+  std::swap(sIndirectLayerTrees[aLayerId].mLayerTreeReadyObserver,
>+    sIndirectLayerTrees[aOtherLayerId].mLayerTreeReadyObserver);
>+}
I'm not familiar with this code, so I shouldn't review it. Especially the threading/lock part of it needs careful review, I guess.
Perhaps billm knows this part.

r+ for other parts except CompositorParent::SwapLayerTreeObservers.
Attachment #8591005 - Flags: review?(bugs) → review+
OK, lets see what billm thinks of the CompositorParent part of the patch.

This patch just updates the last with smaug's cosmetic changes.  Tests in comment 3 are still valid.
Attachment #8591005 - Attachment is obsolete: true
Attachment #8592356 - Flags: review?(wmccloskey)
Duplicate of this bug: 1087969
Attachment #8592356 - Flags: review?(wmccloskey) → review+
Keywords: checkin-needed
https://hg.mozilla.org/mozilla-central/rev/f1f2c9b763fd
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla40
I reproduced the original issue with Nightly from April 5 as described in comment 0. I tested the scenario with the latest Firefox 42 Nightly (BuildID=20150719030219), and the issue seems to be only partially fixed. There are still two visible issues:

1. Launch latest Nightly.
2. Open a New tab and navigate to https://people.mozilla.org/~fqueze2/webrtc/
3. Click on Video or Audio&Video button and select 'Share Selected Devices'.
4. Drag tab with shared video in a New Window.

Issue #1 -> when the tab is detached, the Video works with very low fps (mostly frozen for several seconds)
- the issue reproduced with 3 different webcams on 3 different Operating Systems: Win 7 x64, Mac OS X 10.9.5, Ubuntu 12.04 x86
- quickly clicking inside the tab content seems to update the displayed video frame (otherwise Video is frozen for most of the time)

5. Re-attach tab from step 4.

Issue #2 -> when the tab is reattached, you immediately get the Video working normally on Mac OS X 10.9.5, but you still get the spinner on Windows 7 x64 and Ubuntu 12.04 x86
- as mentioned above issue #2 only affects Windows and Linux
- clicking inside the tab content will eventually restore the Video content, otherwise the spinner keeps displaying

David, it seems that only issue #2 is fixed and only on Mac. Should I reopen this issue or file some follow-up bugs?
Flags: needinfo?(davidp99)
You need to log in before you can comment on or make changes to this bug.