Do Browser Vendors Care About Your WebRTC Testing?
It is 2017 and it seems that browser vendors are starting to think of all of us WebRTC developers and testers. Well… not all the browser vendors… and not all the time – but I’ll take what I am given.
I remember years ago when I managed the development of a VoIP stack, we decided to rewrite our whole test application from scratch. We switched from the horrible “native” Windows and Unix UI frameworks to a cross platform one – Tcl/Tk (yes. I know. I am old). We also took the time to redesign our UI, trying to make it easier for us and our developers to test the APIs of the VoIP stack. These were the good ol’ days of manual testing – automation wasn’t even a concept for us.
This change brought with it a world of pain to me. I had almost daily fights with the test manager who had her team file bugs that from my perspective were UI issues and not the product’s issues. While true, fixing these bugs and even adding more tooling for our testing team ended up making our product better and more developers-friendly – an important factor for a product used by developers.
Things aren’t much different in WebRTC-land and browsers these days.
If I had to guess, here’s what I’d say is happening:
- Developers are the main customers of WebRTC and the implementation of WebRTC in browsers
- Browser vendors are working hard on getting WebRTC to work, but at times neglected this minor issue of empowering developers with their testing needs
- Testing tools provided by browsers specifically for WebRTC are second class citizens when it comes to… well… almost everything else in the browser
The First 5 Years
Up until now, Chrome was the most accommodating browser out there when it came to us being able to adopt it and automate it for our own needs. It was never easy even with Chrome, but it is working, so it is hard to complain.
Chrome gives us out of the box the following set of capabilities:
- Support for Selenium and WebDriver, which allows us to automate it properly (for most versions, most of the times, when things don’t go breaking up on us suddenly). Firefox has similar capabilities
- The webrtc-internals Chrome tab with all of its goodness and data
- Ability to easily replace raw inputs of camera and microphone with media files (even if at times this capability is buggy)
We’ve had our share of Chrome bugs that we had to file or star to get specific features to work. Some of it got solved, while others are still open. That’s life I guess – you win some and you lose some.
Firefox was not that fun, to say the least. We’ve been struggling for a long time with it trying to get it to behave with Selenium inside a Docker container. The end result never got beyond 5 frames per second. Somehow, the combination of technologies we’ve been using didn’t work and never got the attention of Mozilla to take a look at – it may well be our own ignorance of how and where to nag the Mozilla team to get that attention 🙂
Edge? Had nothing – or at least not close to the level that Chrome and Firefox have on offer. We will get there. Eventually.
This has been the status quo for quite some time. Perhaps the whole 5 years of WebRTC’s existence.
But now things are changing.
And they are becoming rather interesting.
Mozilla Wiresharking
Mozilla introduced last month the ability to log RTP headers in Firefox WebRTC sessions.
While Chrome had something similar for quite some time, Firefox took this a step further:
“Bug 1343640 adds support in Firefox version 55 to log the RTP header plus the first five bytes of the payload unencrypted. RTCP will be logged in full and unencrypted.”
The best thing though? It also shared a script that can convert these logs to PCAP files, making them readable in Wireshark – a popular open source tool for analyzing network traffic.
The end result? You can now analyze with more clarity what goes on the network and how the browser behaves – especially if you don’t have a media server in the middle (or if you haven’t invested in tools that enable you to analyze it already).
This isn’t a first for Mozilla. It seems that lately, they have been sharing some useful information and pieces of code on their new Advancing WebRTC blog – a definite resource you should be following if you aren’t already.
Edge Does BrowserStack
Microsoft has been on a very positive streak lately. For over a year now, most of the Microsoft announcements are actually furthering the cause of their customers and developers without creating closed gardens – something that I find refreshing.
When it comes to WebRTC, Microsoft recently released a new version of Edge (in beta still) that is interoperable with Chrome and Firefox – on the codec level. While that was a rather expected move, the one we’ve seen last week was quite surprising and interesting.
An Edge testing partnership with BrowserStack: If you want to test your web app on the Edge browser, you can now use BrowserStack for free to do that (there are a few free plans there for it).
How does WebRTC comes to play here? As an enabler to a new feature that got introduced there:
See how that Edge window inside a Chrome app running on a Mac looks?
Guess what – BrowserStack are using WebRTC to enable this screen casting feature. While the original Microsoft announcement removed any trace of WebRTC from it, you can still find that over the web (here, here and here for example). For the geeks, we have a webrtc-internal dump!
The feature is called “Live Testing” at BrowserStack and offers the ability to run a cloud machine running Windows 10 and the Edge browser – and have that machine stream its virtual screen to your local machine – all assuming the local browser you are using for it all supports WebRTC.
In a way, this is a replacement of VNC (which is what we use at testRTC to offer this capability).
Is this coming from Microsoft? From BrowserStack?
I don’t really think it matters. It shows how WebRTC is getting used in new ways and how browser vendors are a major part of this change.
Will Google even care?
Google has been running along with WebRTC, practically on their own.
Yes. Mozilla with Firefox was there from the beginning. Microsoft is joining with Edge. Apple is slowly being dragged into it if you follow the rumormill.
But Google has been setting the tone through the initial acquisitions it made and the ongoing investment in it – both in engineering and in marketing. The end result for Google’s investments (not only in WebRTC but in everything HTML5 related)? Desktop browsers market share dominance
With these new toys that other browser vendors are giving us developers and testers – may that be something to reconsider and revisit? We are the early adopters of browsers, and we usually pick and choose the ones that offer us the greater power and enable us to speed our development efforts.
I wonder if Google will answer in turn with its own new tools and initiatives or continue in their current trajectory.
Should we expect better tooling?
Yes. Definitely.
WebRTC is hard to develop compared to other HTML5 technologies and it is a lot harder to test. Test automation frameworks and commercial offerings tend to focus on the easier problems of browser testing and they often neglect WebRTC, which is where we try to fill in these gaps.
I for once, would appreciate a few more trinkets from browser vendors that we could adopt and use at testRTC.