1261096 - [e10s] The viewer sees a black screen when sharing the "about:*" pages in a Hello call.

Status: RESOLVED INCOMPLETE

(Hello (Loop) :: Client, defect)

Description

[Ciprian Muresan [:cmuresan], Ecosystem QA]

Attachment: Screenshot from 2016-03-31 18-22-42.png

[Prerequisites]:
- Add the Hello feature to the Menu (if not already added) from customization menu.

[Affected versions]:
Nightly 48.0a1, Build ID 20160331030231

[Affected platforms]:
- Windows 10 x32
- Mac OS X 10.10
- Ubuntu 15.10 x64

[Steps to reproduce]:
1. Open browser and visit a website.
2. Click the Hello button and after the drop-down is displayed, click "Browse this page with a friend".
3. After the guest has joined the call and while in the call, open a new tab and go to "about:config".

[Expected result]:
- The about:config page is displayed for both the Host and the Guest.

[Actual result]:
- A black screen is displayed only for the guest.

[Notes]:
- does not occur with e10s disabled
- also reproducible when viewing "about:support" page

Comment 1

[Mark Banner (:standard8)]

This was intentional: The about:config page (and most of the about:* pages) are not in the content process (they're in the chrome process), and there's a significant amount of work to do to to make tab sharing work continuously across different processes.

We might be able to detect it and put up a message, but that's about it for now.

The work for making tab sharing work across different processes will need to happen sometime but it is extensive and not scheduled into the WebRTC team's platform work for a few months yet.

Comment 2

[Ian Bicking (:ianbicking)]

Maire: in order to present something more attractive than a black screen, Hello would need access to some event that indicates that the tab sharing has been disabled for this tab, which I presume would have to happen at the WebRTC level.  I'm not sure how difficult this is to implement; while the black screen is unattractive it's still acceptable to us if it's difficult to provide more information from the WebRTC layer.

Comment 3

[Maire Reavy [:mreavy]]

jib -- See Ian's request in comment 2.  How hard would it be to provide moz-specific events when a tabcapture stream becomes non-renderable, and when it becomes renderable again?  Thanks

Comment 4

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

On the sending side:

 A. Isn't it simpler for Hello to just check url.startsWith("about:") ?

 B. If not, then in c++ this is probably detectable with DOMMediaStream::GetPrincipal which isn't
    surfaced. But rather than a moz-specific API, maybe we could mute the stream when this
    happens. Then sender-side JS could use .onmute and .onunmute (Bug 1208378).

On the receiving end:

 C. I checked with with jesup, and AFAWK nothing on the wire tells a receiving peer connection
    it's receiving black/silence, so the app should use data channels for this.

A+C seems easiest.

Comment 5

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

Wait, does it recover from black when tabbing away from about:config? If so, then I may be wrong about it having to do with principals, as I think principals get tainted and never recover.

In any case, doesn't change my recommendation.

Comment 6

[Ciprian Muresan [:cmuresan], Ecosystem QA]

It does recover from black when tabbing away from "about:*" pages. And I have observed a different thing: When you share the "about:*" page through a Hello call, the viewer can see it properly, but for any other pages (ex: going to YouTube) they see a black page. Also recoverable when going back to "about:*" pages.

Comment 7

[Munro Mengjue Chiang [:mchiang] Be Mozillian since 1/19/2018]

Maybe this is a hello issue?
I do some experiment:

1. open a tab and browse "about:*", launch hello to share screen.
getusermedia is called; MediaEngineTabVideoSource is created in chrome process.

everything is fine until now.

2. switch to another tab, browse a website
getusermedia is called again (still in chrome process); MediaEngineTabVideoSource is created (in chrome process).

Now it gets weird. Why does hello still call getusermedia in chrome process?

If I start the experiment with opening a tab and browse a website, and then switch to "about:*" tab, all these (getusermedia / MediaEngineTabVideoSource) will run in content process always.

Comment 8

[Mark Banner (:standard8)]

jib: Is there an existing bug we could add as a dependency that'll let us switch process once sharing has started?

Comment 9

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

Not that i know of. Is the issue that Hello code is stuck in the process it first starts in?

Comment 10

[Mark Banner (:standard8)]

Support for Hello/Loop has been discontinued.

https://support.mozilla.org/kb/hello-status

Hence closing the old bugs. Thank you for your support.