The work done by webrtc-in-webkit (mainly Adam B from Ericsson), and a few other contributors (Centricular, Igalia, Canon, Apple, ……) has now found his way to the preview version of Safari!

What is Safari nightly ?

Paul Irish in his blog post explains it better than I could, so here you go:

“it’s the mac port of WebKit, running inside of the same binary that Safari uses (though with a few underlying libraries swapped out). Apple mostly calls the shots in it, so its behavior and feature set is congruent with what you’ll find in Safari. In many cases Apple takes a conservative approach when enabling features that other ports may be implementing or experimenting with.”

Basically, Safari is but a skin around webkit, and Safari Nightly let you reuse this skin with a newer version of Safari, on mac. You can download it here, and play with it, to report bugs against Safari before an official release.

What should I expect ?

When going from one webkit browser to another, you change the “skin” (The UI) but also some very low level parts called “backend”. To be able to tests its work, the WebRTC in WebKit project used the GTK+ browser, which provide access to all parts open source (safari does not provide access to all the parts).

The last post on this blog last December showed you that developer versions of GTK+ were complete enough to achieve interoperability with Chrome. The Safari version is behind, as the changes needs to be ported in the main WebKit repository, and then Apple needs to implement the part in the Safari UI and the corresponding back-end.

Until last week, all the WebRTC code in WebKit was protected behind a compilation flag (MEDIA_STREAM). Earlier last year, this flag was set to ON by default in Safari ports, making all Media Stream and WebRTC APIs available as long as the corresponding binding existed.

However not all the corresponding implementations were done (webcore modules, webcore platform, and back end), resulting in crashes when people start playing with it. To protect Safari Nightly users against those crashes, while the work on webrtc is ongoing, a new flag has been added. The MEDIA_STREAM tag now protects the media stream implementation, and is ON by default, the WEB_RTC tag now protects webrtc only code.

Practically, all the media stream specifications have been implemented (getUserMedia, connection to an <audio> or <video> tag, …..) and are usable (*) today, but not the WebRTC (peer connection API, Object Model API) yet, using Safari Nightly.

(*) The devil is always in the detail. While the API is present, Safari Nightly re-uses the safari UI, which does not include the infamous security prompt. Basically, you can see the APIs, but you cannot use them, because the getUserMedia security prompt never shows and the calls time out. Using the latest updates of the W3C media stream test suite (here, and there), and the updated adapter.js, the safari compliance test goes up from 0 to 4, but still far away from Chrome, Firefox and Edge scores (between 45 and 50).

What’s next?

If you’re a developer, there is hope for you to test webrtc right away, if you’re not, you have to wait for the next version of Safari UI that will integrate the security prompt. The W3C web platform test will then work out of the box, and the results will be directly comparable across browsers.

If you’re a dev, and can recompile webkit, the testing mechanism in webkit does not (and should not) include the browser UI. That allows you to by-pass safari UI limitations.

As a result, most of the tests are run within an executable (test runner or mini browser) that includes a way to keep UI settings in memory, and to set them programmatically. The LayoutTests in webkit are single html pages that can be run, theoretically within a browser, or within the above-mentionned binaries.

Code works in both environment by using the following guard in JS:

if (window.testRunner) {
  /** do something specific to test runner */
}

Specifically for media streams, you can sets and check an in-memory cache of the per-origin permission settings, specifically:

• TestController::setUserMediaPermissionForOrigin [code here]
• TestController::handleCheckOfUserMediaPermissionForOrigin [code here]
• TestController::handleUserMediaPermissionRequest [code here].

One can take a look at the media stream testing folder for more JS examples.

WebKit2 calls through the page UI client, which in WebKitTestRunner is set up in TestController::createOtherPage:

    WKPageUIClientV6 otherPageUIClient = {
        { 6, view },
        0, // createNewPage_deprecatedForUseWithV0
        ...
        0, // isPlayingAudioDidChange
        decidePolicyForUserMediaPermissionRequest,
        0, // didClickAutofillButton
        0, // runJavaScriptAlert
        0, // runJavaScriptConfirm
        0, // runJavaScriptPrompt
        0, // mediaSessionMetadataDidChange
        createOtherPage,
        0, // runJavaScriptAlert
        0, // runJavaScriptConfirm
        0, // runJavaScriptPrompt
        checkUserMediaPermissionForOrigin,
    };
    WKPageSetPageUIClient(newPage, &otherPageUIClient.base);

Note: MiniBrowser doesn’t currently implement page UI client

Funny enough, the spec coverage is higher with those webkit tests than with the W3C web platform test suite. There is an ongoing effort to bring everything in sync between the test suites, and with the specs.

Conclusion

GUM.

All of the code for getUserMedia is already here and tested. While not available to the general public for practical reasons, the availability in next safari version (no, not 9.1) is almost a given.

WEBRTC.

Most of the code for PeerConnection is there, but hidden behind a flag and only available to developers that would build webkit on their machine.

Moreover, while all the JS APIs are present and have been updated, including contribution from Canon France for the promises, while all the corresponding webcore objects are implemented, and the tests have been already written, the back-end implementation has only been done for GTK+ today.

Additional work from apple is needed to provide a back end implementation. See this slide show, slide #40, the back-end part is in pink. That’s almost the only missing piece today. If they were to approach it like they approached the media stream implementation, they might not reuse GStreamer / OpenWebRTC but native Apple APIs.