Support & information center

Like everything else you can do with WebRTC, screen sharing is natively supported by testRTC. There are though a few things you should be aware of and prepare in advance with if you want to test and validate your screen sharing feature with testRTC.

1. Understanding browser tabs in testRTC

When using screen sharing, you are going to move between tabs.

testRTC may or may not open chrome://webrtc-internals tab for its own use, which can confuse certain scripts.

This is why we make use of process.env.RTC_EXTRA_TABS environment variable. You can learn more about switching windows and tabs in testRTC.

2. Use run options to grab the whole screen

You can’t automate the screen picker modal of Chrome. What you can do instead is let Chrome know you wish to override that modal and always capture the whole screen.

To do that, add the following string to your run options:

#chrome-cli:auto-select-desktop-capture-source=Entire screen,enable-usermedia-screen-capturingCode language: PHP (php)

3. Pick a video to share

With WebRTC, a user is likely to click a screen sharing button and then move on to a different tab in his browser or a different application that he is sharing. You’d want to do that as well, to keep the screen that WebRTC encodes as dynamic as possible.

For that purpose, think of a YouTube video that you would want to share. My preference is a movie preview, but that’s not always what you’re looking for. Here are two alternatives we use from time to time:

1. A rather static presentation (this link)
2. Big Buck Bunny – a classic… (this link)

Notice that we use the following URL format for YouTube:

youtube.com/embed/?playlist=<video-id>&autoplay=1&loop=1

• embed causes the video to load in full screen mode
• autoplay will… auto play the video
• loop will cause the video to loop once completed, so you don’t have to worry about its length

4. Tab switching

Once you click the share button on your UI, it is time to open a new and open that YouTube video URL.

Here’s how we do it usually:

function startedSharing() {
    client
        .rtcEvent('Screen Share ', 'global')
        .rtcScreenshot('screen share')

        .execute("window.open('" + videoURL + "', '_blank')")
        .pause(5 * sec)

        // Switch to the YouTube tab
        .windowHandles(function(result) {
            var newWindow;
            newWindow = result.value[1+Number(process.env.RTC_EXTRA_TABS)];
            this.switchWindow(newWindow);
        });
}
Code language: JavaScript (javascript)

A few observations here:

• You can place this function as one of your assets
• Adding an event using rtcEvent() at the beginning comes in handy when you’ll view the resulting graphs in the end
• The videoURL is that YouTube URL we’ve shared earlier. Use a variable for that so it will be easier to search and modify based on your needs
• Actual window switching is done using pure Nightwach commands

If you want/need to switch back and stop screen sharing, you can use this piece of code:

function stoppedScreensharing() {
    client.windowHandles(function (result) {
        var newWindow;
        newWindow = result.value[Number(process.env.RTC_EXTRA_TABS)];
        this.switchWindow(newWindow);
    });
}Code language: JavaScript (javascript)

Just don’t forget to click the stop screen sharing button in your UI afterwards.

5. Select who is going to screen share

Use our sessions mechanism to split your test into sessions (a session is a room usually). In each session, have a single probe screen share and the rest designated viewers.

Here’s how you can do that:

var probeIdx = Number(process.env.RTC_IN_SESSION_ID);
var sec = 1000;

if (probeIdx === 1) {
    // Screen share here
}

client.pause(60*sec);

if (probeIdx === 1) {
    // Stop screen sharing here
}Code language: JavaScript (javascript)

6. Take a screenshot on the viewers’ side

For debugging purposes, you can use rtcScreenshot() to take a screenshot of what gets shared for those who aren’t screen sharing.