1137634 - [e10s] Sharing a tab/ browser source does not work

Status: RESOLVED DUPLICATE of bug 1048850

(Hello (Loop) :: Client, defect, P2)

Description

[Mike de Boer [:mikedeboer]]

Sharing a tab in Loop works like a charm for non-e10s browsers, but not for e10s enabled ones.

Browser sharing works by passing the outerWindowID of the browsers' contentWindow to gUM. First discrepancy that I see between the retrieved outerWindowIDs - from a fresh startup, no session restore - is that non-e10s IDs are relatively small numbers (< 10) and e10s IDs are way larger numbers (> 1000).

The result of attempting to share an e10s browser is that the receiving end receives an entirely black stream, instead of the window's contents.

Comment 1

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

Is this on all platforms or OSX? e.g. potentially related to Bug 1083344 ?

Comment 2

[Bill McCloskey [inactive unless it's an emergency] (:billm)]

Brad, what should we do with Loop bugs?

Comment 3

[Mike de Boer [:mikedeboer]]

(In reply to Jan-Ivar Bruaroey [:jib] from comment #1)
> Is this on all platforms or OSX? e.g. potentially related to Bug 1083344 ?

I only reproduced this on OSX.

Comment 4

[Mark Banner (:standard8)]

This will soon block us from turning on Tab sharing in nightly builds.

Comment 5

[Brad Lassey [:blassey] (use needinfo?)]

(In reply to Bill McCloskey (:billm) from comment #2)
> Brad, what should we do with Loop bugs?

Bill, this isn't a bug the e10s team needs to track.

Mike, as I said in the bug that implemented this, tab sharing works under e10s for tab mirroring. This is a hello bug, not a platform bug.

Comment 6

[Mark Banner (:standard8)]

Has anyone got an up-to-date testcase that shows e10s working for tab mirroring?

All we're doing is getting the outerWindowId and passing that along to the platform via the gUM request...

Comment 7

[Mike de Boer [:mikedeboer]]

(In reply to Brad Lassey [:blassey] (use needinfo?) from comment #5)
> Mike, as I said in the bug that implemented this, tab sharing works under
> e10s for tab mirroring. This is a hello bug, not a platform bug.

Please see comment 6.

You gave me a few hints to use the Roku simulator and go through the code paths it uses. I did and I could _not_ get it to work. The code path used by the mirroring code is similar, if not identical, to the thing we're doing in Loop. This is also something I've stated multiple times.
I'm not interested in jumping through hoops to see if I can _maybe_ get this simulator to work on Windows or Linux.

This could very well be an OSX-only issue, as hinted by :jib in comment 1, but that I don't know. All I do know is that this makes it a platform issue. Please, let's not play the ping-pong game and get to something that works, together.

Comment 8

[Mark Banner (:standard8)]

I've actually got the Roku simulator working at the moment.

Here's the constraints we're passing to the gUM for Roku:

{"video": {
  "mediaSource":"browser",
  "browserWindow":2147483649,
  "scrollWithPage":true,
  "advanced": [{
     "width":{"min":0,"max":1280},
     "height":{"min":0,"max":720}},
     {"aspectRatio":1.7777777777777777}
  ]}
}

and now for Loop:

{video: {
  mediaSource: "browser",
  browserWindow: 2147483649,
  scrollWithPage: true
}

So we're passing everything the same, except for the advanced properties - which I wouldn't expect we'd need, but I'll give it a try.

Comment 9

[Mark Banner (:standard8)]

Ok, I've matched the constraints and verified the output's the same, but still no luck.

Roku simulator works fine with exactly the same build of FF on this Mac.

Please can we have someone from the core team to look at this?

It feels like its either a platform issue, or we're telling the platform something wrong. However, since I've matched the constraints, I've no idea what bit we might be missing nor where to start looking for it.

Comment 10

[Mike de Boer [:mikedeboer]]

(In reply to Mike de Boer [:mikedeboer] from comment #3)
> (In reply to Jan-Ivar Bruaroey [:jib] from comment #1)
> > Is this on all platforms or OSX? e.g. potentially related to Bug 1083344 ?
> 
> I only reproduced this on OSX.

Sorry, I wasn't quite clear here. What I meant is: I only tested this on OSX so far. I will test it today on Linux and Windows.

Comment 11

[Mark Banner (:standard8)]

I just tried inspecting the received video in e10s mode, and the videoHeight and videoWidth were both 0. So it seems like the stream isn't being transmitted.

Comment 12

[Randell Jesup [:jesup] (needinfo me)]

So: the main problem here is that the tab contents live in the content process, and Loop (in e10s mode) is running in the master process.  Attempting to render the content of the tab into a buffer for insertion into the MediaStreamTrack from the master process almost certainly cannot work.

The correct solution to this is to have the Loop media application (SDK + platform code) run in the content process, and communicate via IPC with the UI elements running in the master (chrome) process, like other Chrome<->platform interactions.

Hacks (evil/painful ones) are possible, but I would not recommend them.  Alternatively disable tab-sharing in e10s and have it tell the user to disable e10s to use it.

Comment 13

[:shell escalante]

Before March 23rd Mike, Mark, and Randell will have a preliminary talk on e10s impacts to Hello/webRTC.  This needs to be among the work in Fx40 so it isn't broken when e10S is expected to go to Beta.  https://wiki.mozilla.org/Electrolysis#Schedule

Move up when setting Fx40 priorities and the plan of addressing is further along.

Comment 14

[Mike de Boer [:mikedeboer]]

We just had this discussion and the road to full e10s compatibility is very clear. This'll boil down to a couple of bugs that I'll file tomorrow to get a good picture of the amount of work.

Comment 15

[Mark Banner (:standard8)]

Syncing priority with the other e10s bugs.

Comment 16

[Jan-Ivar Bruaroey [:jib] (needinfo? me)]

(In reply to Mark Banner (:standard8) from comment #6)
> Has anyone got an up-to-date testcase that shows e10s working for tab
> mirroring?

See working tab demo in bug 1193075 comment 32 and bug 1193075 comment 33. Works for me in e10s FWIW.

Comment 17

[:shell escalante]

moved down as we need to check once the e10s bugs lands...but not a work bug.