Closed Bug 1137634 Opened 5 years ago Closed 4 years ago

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

Categories

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

defect

Tracking

(e10s-)

RESOLVED DUPLICATE of bug 1048850
Tracking Status
e10s - ---
Blocking Flags:
backlog backlog+

People

(Reporter: mikedeboer, Unassigned)

References

Details

(Whiteboard: [web sharing][e10s][validated once 1048850 lands])

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.
Flags: qe-verify+
Is this on all platforms or OSX? e.g. potentially related to Bug 1083344 ?
Brad, what should we do with Loop bugs?
Flags: needinfo?(blassey.bugs)
(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.
This will soon block us from turning on Tab sharing in nightly builds.
Severity: normal → major
(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.
Component: WebRTC → Client
Flags: needinfo?(blassey.bugs)
Product: Core → Loop
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...
(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.
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.
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.
(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.
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.
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.
Blocks: 1140313
See Also: → 1141059
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.
Rank: 34
Flags: firefox-backlog+
Priority: -- → P3
Whiteboard: [e10s][Fx40]
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.
backlog: Fx38? → backlog+
QA Contact: bogdan.maris
Depends on: loop-e10s
Rank: 34 → 32
Whiteboard: [e10s][Fx40] → [e10s][Fx44]
Blocks: 1214215
Syncing priority with the other e10s bugs.
Rank: 32 → 16
Priority: P3 → P2
Whiteboard: [e10s][Fx44] → [web sharing][e10s][Fx44]
(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.
Iteration: --- → 45.2 - Nov 30
moved down as we need to check once the e10s bugs lands...but not a work bug.
Rank: 16 → 22
Whiteboard: [web sharing][e10s][Fx44] → [web sharing][e10s][validated once 1048850 lands]
No longer blocks: 1214215
Iteration: 45.2 - Nov 30 → ---
Status: NEW → RESOLVED
Closed: 4 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1048850
You need to log in before you can comment on or make changes to this bug.