Level Up Your Cross-Browser Testing

Today we’re announcing a special opportunity for web developers to learn how to build and automate functional browser tests — we’ve partnered with Sauce Labs to offer a special extended trial of their excellent tools, and we’ve created a custom learning resource as part of this trial.

2016: The year of web compat

In 2016 we made a lot of noise about cross-browser compatibility:

Let there be no question: Cross-browser compatibility is essential for a robust, healthy internet, and we’ll continue urging developers to build web experiences that work for more people on more browsers and devices.

That is by no means the end of it, however — we also intend to make it easier to achieve cross-browser compatibility, with tools and information to help developers make the web as interoperable as possible.

Special access to Sauce Labs

Beginning today, we’re introducing an exceptional opportunity for web developers. Our partners — Sauce Labs — are giving web developers special access to a complete suite of cross-browser testing tools, including hundreds of OS/browser combinations and full access to automation features.

The offer includes a commitment-free extended trial access period for Sauce Labs tools, with extra features beyond what is available in the standard trial. To find out more and take advantage of the offer, visit our signup page now.

Access to Mozilla’s new testing tutorials

We’ve also brought together expert trainers from Sauce Labs and MDN to create a streamlined tutorial to help developers get up and running quickly with automated website testing, covering the most essential concepts and skills you’ll need: See Mozilla’s cross-browser testing tutorial.

What’s next

This is a time-limited offer from our friends at Sauce Labs. We want to understand whether access to tools like this can help developers deliver effective, performant, interoperable web experiences across today’s complex landscape of browsers and devices.

Sign up and let us know how it goes. Is the trial helpful to you? Do you have constructive feedback on the tooling? Please let us know in the comments below.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Cross-browser camera capture with getUserMedia/WebRTC


With Firefox adding support for getUserMedia, three of the major desktop browsers now have the ability to get data from cameras without the use of plugins. As it’s still early days, however, the implementations differ slightly between browsers. Below is an example of how to work around these differences and a script to do the heavy lifting for you, but first, an overview of how the three browsers stack up.

Comparison of getUserMedia behaviour in browsers as of February 2013
Firefox 18 Opera 12 Chrome 24
Requires vendor prefix Yes (moz) No Yes (webkit)
Triggered with autoplay attribute No Yes Yes
Requires enabling by user Yes 1 No No
Firing of playing event Repeatedly Once Once
Supports file:// protocol Yes Yes No
Tab playing notification None Icon Animated icon
Permission request Each page load First page load only Each page load

getUserMedia has to be enabled in Firefox by setting the media.peerconnection.enabled option to true in about:config.

There are a few more differences once we start coding so let’s walk through it. Our recipe for getUserMedia success will be broken down into the following easy steps:

  1. A helping of HTML5
  2. A dollop of feature detection
  3. A spoonful of streaming
  4. Ready for serving
  5. A final tip

Deep breath – here we go…

A helping of HTML5

Our main task in this short tutorial is just to get a moving image displaying in a page. In that respect, it’s no different to regular video so the first step is a simple <video> element in our HTML:


That’s it. No controls, no src, no nothing.

Over to the JavaScript, and obviously we need to get a reference to the <video> element, which we can do like so (or alternatively with an id):

var video = document.querySelector('video');

A dollop of feature detection

Now it gets interesting as we check for getUserMedia support. We’re definitely not going to use unreliable user agent sniffing for this — no, we’ll do it the easy way by checking for the navigator.getUserMedia object. This is prefixed in Firefox and Chrome so first it’s handy to assign it to a common object for all browsers. While we’re at it, let’s do it for the window.URL object as well which we’ll use later on.

navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia;
window.URL = window.URL || window.webkitURL || window.mozURL || window.msURL;

And next, the actual existence checking:

if (navigator.getUserMedia) {
    // Call the getUserMedia method here
} else {
    console.log('Native device media streaming (getUserMedia) not supported in this browser.');
    // Display a friendly "sorry" message to the user.

If getUserMedia is supported, we need to pass it three arguments — an options object, a success callback function and an error callback function. Note that the error callback is required in Firefox but optional in Opera and Chrome. The options argument is a JSON-style object that specifies whether audio, video or both are to be used. The following example code is for video only:

navigator.getUserMedia({video: true}, successCallback, errorCallback);

Dialogs requesting camera access

Dialog in Firefox

Dialog in Google Chrome

Dialog in Opera

A spoonful of streaming

So far so good, so let’s define what happens next. The success callback function receives an argument containing the video stream from the camera and we want to send that stream to our <video> element. We do this by setting its src attribute but there are a couple of things to bear in mind:

  • Firefox uses the mozSrcObject attribute whereas Opera and Chrome use src.
  • Chrome uses the createObjectURL method whereas Firefox and Opera send the stream directly.

With Firefox, we can’t check for the existence of video.mozSrcObject because it’s undefined until it receives a stream, but there’s a related video.mozCaptureStream method which we can rely on instead for detection. Once the stream knows where to go we can tell the video stream to play.

function successCallback(stream) {
    if (video.mozCaptureStream) {
        video.mozSrcObject = stream;
    } else {
        video.src = (window.URL && window.URL.createObjectURL(stream)) || stream;

Ready for serving

And there you have it. Add a simple error callback function and we have a working cross-browser script which looks something like this:

window.addEventListener('DOMContentLoaded', function() {
    'use strict';
    var video = document.querySelector('video');
    function successCallback(stream) {
        // Set the source of the video element with the stream from the camera
        if (video.mozCaptureStream) {
            video.mozSrcObject = stream;
        } else {
            video.src = (window.URL && window.URL.createObjectURL(stream)) || stream;
    function errorCallback(error) {
        console.error('An error occurred: [CODE ' + error.code + ']');
        // Display a friendly "sorry" message to the user
    navigator.getUserMedia = navigator.getUserMedia || navigator.webkitGetUserMedia || navigator.mozGetUserMedia || navigator.msGetUserMedia;
    window.URL = window.URL || window.webkitURL || window.mozURL || window.msURL;
    // Call the getUserMedia method with our callback functions
    if (navigator.getUserMedia) {
        navigator.getUserMedia({video: true}, successCallback, errorCallback);
    } else {
        console.log('Native web camera streaming (getUserMedia) not supported in this browser.');
        // Display a friendly "sorry" message to the user
}, false);

Available on GitHub

To get started with accessing getUserMedia in a cross web browser fashion, we have also put a working example on GitHub: GumWrapper.

A final tip

If you want to do anything fancy with the camera’s stream like capture a still image or add fancy effects, you’ll probably want to send its data to a canvas context. You can use drawImage() for this, in which case you’ll need the dimensions of the video. These are available through the video.videoWidth and video.videoHeight properties but beware — they’re only set when the browser has information about the stream. This means you have to listen for certain events before you can get these properties. There are a few relevant events, always fired in the following order:

  1. play
  2. loadedmetadata
  3. loadeddata
  4. playing

The play event is fired after the method is called but there may be a slight delay before the video actually starts playing. That’s where the playing event comes in but note that it’s fired repeatedly in Firefox while the stream or video is playing. Before that are a couple of data events, the first of which is just for metadata, however in Firefox this doesn’t include video dimensions. Consequently, the most reliable event to listen for is the loadeddata event — you can then be sure of knowing the width and height of the video stream. You could code it up like this:

video.addEventListener('loadeddata', function() {
console.log('Video dimensions: ' + video.videoWidth + ' x ' + video.videoHeight);
}, false);

Incidentally, you could also use the stream’s dimensions as a further error check, for example checking whether the width and height are above 0. This would avoid problems such as the user’s webcam being broken or simply not plugged in.

And there you have it. I’m sure the differences between browsers will disappear as the technology matures but for the time being, the above code should help you on your way.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Developer survey results: libraries and cross-browser on mobile?

At Mozilla, we are dedicated to keep the web open and independent of a single company or technology. This means that users should have a choice of browsers and technology to use to go online and should not be blocked out because they can’t afford a certain device or are forbidden to change their browser.

In the world of mobile web development there is currently a massive debate going on about the need for support of various browsers seeing that the most successful phone systems both use the same browser engine. This is good, and we need this debate. It is not good though when developers block out users because they concentrate on targetting a browser. Sometimes this is not by choice of the developer – they are simply using tools that do that blocking for them and the usefulness of the tool outweighs the qualms developers have about that.

We are currently talking to library and tool developers and help them support more than one browser engine to prevent this. As a start of that process we wanted to get a glimpse of what people are using right now so we make sure we have the most impact when we help. This is why we conducted an online survey asking developers about their tools for mobile development.

590 developers took the survey and we are thankful for them spending their time giving us a lot to ponder and think about.

We are very aware that this is *not* a scientifically clean research and should be taken with a grain of salt (we haven’t asked how many times people used the tools or how much of their work is building mobile apps) but it gives us a good idea of what is going on.

So without further ado, here are the numbers as charts with a quick commentary:


A lot of developers showed their love for the web in this survey, but then again it was a survey initiated by Mozilla. Most likely an Apple-lead survey would have different results. iOS and Android are the follow-up and Windows Phone and Blackberry are less of a concern for the developers who filled the survey. This, of course, could differ greatly were we do to this survey targetted to different markets. Interesting that in the case of Android the amount of “must have” is higher than “focus” – the only platform showing this.

What platforms are you targeting with your apps – Web
focus 370 63%
must have 153 26%
supported 33 6%
sometimes 23 4%
not at all 11 2%
What platforms are you targeting with your apps – iOS
focus 261 44%
must have 207 35%
supported 53 9%
sometimes 28 5%
not at all 41 7%
What platforms are you targeting with your apps – Android
focus 182 31%
must have 221 37%
supported 102 17%
sometimes 47 8%
not at all 38 6%
What platforms are you targeting with your apps – Windows phone
focus 10 2%
must have 46 8%
supported 131 22%
sometimes 173 29%
not at all 230 39%
What platforms are you targeting with your apps – Blackberry
focus 8 1%
must have 15 3%
supported 100 17%
sometimes 164 28%
not at all 303 51%

People may select more than one checkbox, so percentages may add up to more than 100%.


In the world of libraries jQuery and jQuery mobile very much took the lead with more than 200 more uses than the next follower Zepto.js. A lot of feedback was that developers don’t like libraries and use their own hand-rolled solutions on mobile instead. While it is good to see that libraries that work cross-browser are the most used ones (jQuery just announced that they happily support Firefox mobile), the high number of Sencha users is worrying and we’ll see how we can help make their cross-browser support better. Sencha was also mentioned a lot in the “why webkit only” question which shows that it is an important tool for developers.

What libraries do you use to build mobile web apps/sites?
jQuery 437 74%
jQuery mobile 301 51%
Zepto.js 116 20%
JO 5 1%
XUI.js 23 4%
Sproutcore 9 2%
Sencha touch 88 15%
JQTouch 61 10%
Mootools mobile 16 3%
M project 1 0%
Nimblekit 2 0%
Lime.js 10 2%
Wink 2 0%
Uxebu Bikeshed 1 0%
Other 152 26%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 66 libraries (in order of popularity): jQuery, jQuery mobile, Zepto.js, Sencha Touch, JQTouch, XUI.js, Backbone, Mootools mobile, Lime.js, Sproutcore, Angular JS, Underscore, Bootstrap , Enyo, Modernizr, Dojo, handlebars, JO, Closure, Dojo Toolkit, GWT, Hammer.js, iScroll, require.js, YUI, Chibi, Ember.js, Kendo, Kinetic, Lungo.js, Nimblekit, Prototype, Wink, Adobe Air, Atto, Box2D, ChesterGL, Cobra, Crafty, Cujo, d3.js, Dart , Dojo Mobile, Dojo Mini, enhance.js, Eyebrow.js, fitml, gl-matrix, H5BP, JQMobi, Javelin, Jukebox, Knockout, MProject, Mootools, Openlayers, Path , Playcanvas, pointer.js, Raphael, Sugar.js, TerrificJS, Thorax, Titanium Mobile, Uxebu bikeshed, Wakanda

Conversion frameworks

There is no doubt that Phonegap / Cordova rules this segment of the market followed by Appcelerator. Quite a lot of feedback was also people claiming that native apps should be coded natively. Being a web evangelist, I disagree as you can not convert from native to web but the other way around, but it is interesting to see that developers felt the need to have their say here.

Which frameworks do you use to convert apps to native apps?
PhoneGap 325 90%
Appcellerator 50 14%
MoSync 2 1%
Other 38 10%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 13 conversion tools (in order of popularity): Phonegap, Adobe Air, Apache Cordova, Cocoon.js, Brightcove App Cloud, Mosync, Sencha Native SDK, appMobi, Flex Mobile, Mobileweb, Monotouch and backbone.

Visual editors

Not many developers seem to use visual editors, which is probably because most of them are still in a “beta” or “alpha” stage. It would be interesting to do the same survey with Flash developers who are moving towards HTML5 and see if the numbers are higher. As it stands, Adobe Edge and Sencha Animator are the clear winners, and some of the entries were interesting including one “you got to be kidding me” :).

Do you use any visual tools/converters to build apps? If so, which?
Adobe Edge 19 36%
Sencha Animator 10 19%
Other 25 47%

People may select more than one checkbox, so percentages may add up to more than 100%.

All in all we collected 17 editors (in order of popularity): Adobe Edge, Sencha Animator, Adobe Dreamweaver, Adobe Flash, Adobe Photoshop, Codiqua, Construct 2, Hype, Playcanvas , Radi, Rhodes, Telrik, Tiggzi, Tiler, Wakanda, Web Developer Add-on, WebMatrix

Webkit only?

71% of developers filling out the survey said they test for more than Webkit browsers and in the general feedback section of the survey we had a lot of information as to how people are testing and what would make things much easier for them. This makes us happy of course.

Do you test on non-Webkit browsers?
Yes 421 71%
No 169 29%

Reasons to test for webkit only

The main reason here is a lack of time to test on other platforms which is understandable – we can assume that a lot of projects from a planning perspective have 99% iOS/Android written all over them. The “lack of incentive” number is high, too, which is understandable – if you can’t show the numbers, you don’t get the time to support. The high number of “not supported on hardware” is of course another very understandable reason and we wished there would be a way to change this.

Fixed environment defined by client needs 46 24%
Lack of time to support more browser platforms 103 55%
Lack of incentive – I don’t know what the benefit of supporting more is 79 42%
Lack of documentation how to install and debug on non-webkit browsers 43 23%
Bugginess of other browsers on test platforms 31 16%
Lack of support for other browsers on target hardware 68 36%
Other 20 11%

People may select more than one checkbox, so percentages may add up to more than 100%.

Webkit only technology

The question “What technologies/features do you use on Webkit browsers that are crucial for you and not available on others?” was answered by 135 developers and only partly answered what we needed to know. A lot of it wasn’t features of Webkit but general speed and availability reasons that are reliant on the operating system and the hardware. A lot of the answers also simply stated that these browsers come with the hardware which means end users have them and developers don’t have an overhead of installing other browsers or tools. However, quite a few developers praised the predictability of a “one browser platform web” and not having to worry about vendor prefixes and differences in html5 support.

What can mobile Firefox do better?

The question “If yes, what could Firefox mobile provide to make your life easier?” got around 230 answers and is a great resource for us to improve the browser. The message that came across loud and clear was the need for remote debugging for Firefox Android which was just announced here on the hacks blog. It is obvious that developers do not want to have a long gap between writing code and seeing the results on their phones – very understandable indeed. Quite in demand was also a native simulator for the Desktop to avoid the need of having a phone at all. Another thing that stood out was support for older and more hardware.

Anything else?

The “Anything else you want to get heard?” question got 73 answers with a lot of great feedback, especially praise for what is happening right now in the world of Mozilla and some very detailed concerns of developers. We now have a great time going through these answers and will see how we can accelerate a few of the demands in our next browser builds.

Check the results

We’ve uploaded the anonymised answers as a spreadsheet to Google Docs, so feel free to read and dig at your own leisure: Mozilla libraries survey.

A huge Thank You

Last but not least, we want to say Thank you! to everyone who participated. We now have a lot of insightful information and can focus our outreach to frameworks, tools and libraries that will have the most impact when it comes to supporting a cross-browser web. We were also very positively surprised that the trolling and fanboi-ing was kept to a bare minimum – this showed us that the topic really is important for all developers out there.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)