Since the announcement of WebRTC in safari, a lot of blog posts, webinars, and meet-up have surfaced. That was not a surprise for anyone really. I have been writing about webrtc in webkit and Safari for years now, so I was in no hurry, and waited untill the noise level went down. While people where quickly to point the (perceived) mistakes and missing pieces, I do not think anybody has done a real overall comparison between existing browsers see, overall, which was most webrtc-compliance, i.e. future proof. This post is trying to address this.

How to get webrtc-enabled Safari?

You have two choices:

• enroll to the developer program (i.e. pay) and install high sierra (macOS 10.13) that comes with Safari 11, which in turns support webrtc. This is considered the stable Safari version, and while it might gets a few updates in the next weeks, it will not fundamentally change untill next release, sometimes next year.

 

• Use Safari Tech Preview (STP thereafter), for free. STP 32 more or less matches Safari 11, but STP 33 brought in a lot of fixes, and the capacity to fully automate WebRTC testing. More on that below. This works under both Sierra (10.12) and High Sierra (10.13) and i the way we recommend for people to test their software against for now. STP is updated every two weeks or so, so you should be able to stay very close to the )sometimes too sharp) cutting edge.

How to test WebRTC compliance?

As explained in a previous post, the world wide web consortium has it s own test suite, part of “test-the-web-forward” effort, called WPT (Web Platform Test). I have already talked in previous posts about the set-up to test against Safari in general, I will address STP 33 here specifically.

Thanks to the outstanding efforts from CoSMo’s own Soares Chen, and great reviews from BoCoup’s rick waldron, the number of test for webrtc spec went from 50+ last year, to 200+ on June 6 and almost 800 today! The coverage is unsurprisingly improving, and the test suite represents today a great compliance indicator.

How to deal with no-camera, security prompt, HTTP/local server when manually testing or for Selenium instrumentation?

If you run the WPT manually on your computer you can of course always click on the UIs whenever you are prompted. Of course, some test are expecting you to click NO to succeed, so this can be interesting.

if you run more advanced tests, using selenium, and safari is on your machine, you can again get away with clicking yourself.

To really automate testing, chrome as command line switches, and Firefox use profiles, both of which are supported by most selenium clients.

As far as Safari and SPT are concerned, there are good news and bad news.

First, safari announced earlier this year the availability of safari web driver for safari 10+! The web driver implementation is bundled and distributed with safari. For STP, the corresponding web driver executable is in a different, but predictable, location. Safari selenium implementation provides a method to indicate you are using SafariTechPreview and it finds it for you (the syntax may vary depending on the language wrapper you use). It is somehow simpler than Chrome and Firefox.

Now, there are options in Safari to enable and disable almost anything related to WebRTC, from media device listing, to ice candidate filtering, network address detection, etc . That’s good. The “fake media”, called mock’ed media, is awesome, with hold for spatial frequency quality testing and so on!

The bad news is that most of them are not accessible except if you are a webkit developer yourself and know how to enable specials internal debugging tools and menu.

The ugly? Some options are not even available through those well hidden menus, and can only be toggled from the command line, if you know their name. Also, those are developers options, comes with absolutely no support commitment, and shall disappear anytime.

I strongly suggest not to try to use them now, unless you have a webkit guru close to you, and even in that case, just for small scale testing. Apple, along all the other browser vendors, is working on extending WebDriver to be able to handle it through the web driver protocol which admittedly will be a much better, and standard, way of dealing with this problem.

What are the results?

On june 6, I had done a quick test of compliance, and Firefox came out on top. That was then.

W3C (unmodified) #webrtc Test scores. The most compliant browser out of the box is …..#firefox. pic.twitter.com/DV4pe520ue

— Dr. Alex. Gouaillard (@agouaillard) June 6, 2017

In the mean time, 600 more tests have been added to the test suite, and quite a few bugs, especially on GetUserMedia, were fixed by the apple team.

In the new results, while chromium is narrowing the gap with firefox, Safari comes out first!

chromium

firefox

STP 33

Conclusion

I hope this post will help people to get the big picture, and to learn how to get, install and test a webrtc-enabled Safari.

Safari implementation of WebRTC is of course not perfect, and so is the implementation of the other browsers with an average 50% of WebRTC implemented.

Do not let this hide the fact that less than 15 days ago, there was absolutely no support for WebRTC in Safari, or iOS hybrid apps.

The same people that were complaining about that and asking apple to do something, Anything! about it, are today complaining about something else. There are only two kinds of people that can complain that much and get away with it: french citizens (but then it would mean they are not on strike or on vacation, so it’s quite unlikely), and some recently victorious politicians in native english speaking countries of the north hemisphere sharing taste for unlikely haircut of their once blonde hairs.

This is huge! We’ve just got the pony we have bee nagging our parents about for years, it’s not the time to complains it’s not white enough 🙂 Let’s take safari for a ride, test it, report bugs, and help apple make it better.